On Thu, May 7, 2015 at 4:24 AM, Virendra Kumar Pathak kumarvir.pathak@gmail.com wrote:

I am new to gcc development. I am trying to write a new md file describing pipeline information for a processor. Please suggest some good reference document for understanding machine description file.

There is some documentation for pipeline descriptions in the gcc manual. https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html#Pr...

Or if you want the entire docs for the md file, you can find them here https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc This is in the gcc/doc/md.texi file if you want to read the documentation source.

For first integer pipeline following is defined - (define_cpu_unit "cortex_a53_slot0" "cortex_a53")

Is name cortex_a53_slot0 is a keyword or it is any general string? Is there any convention in choosing names for cpu units? If ‘cortex_a53_slot0’ a general string, how assembler knows it is first integer pipeline?

It is a general string, that needs to be unique. Putting the processor name in there helps make it unique across different processors. The rest of it is just something that makes sense for the target, preferably something that maps to the processor documentation.

The compiler does not know that it is the first integer pipeline. All it knows is that some following define_insn_reservation patterns use it. These define_insn_reservation patterns will map the cortex_a53_slot0 cpu unit to the set of instructions that can execute on the first integer pipeline.

How these *.md files are used? When they are compiled and how they are used?

There are various genX programs that read the md file and generate a insn-X.c file to perform actions based on info in the md file. For instance genrecog creates the insn-recog.c file, which is for recognizing RTL patterns that map to valid instructions on the target. genemit creates the insn-emit.c file which emits the assembly code for an RTL insn. Etc.

How to verify an md file for a processor is written correctly or not? How to test it?

It is generally not possible to verify that a md file is correctly written. All you can do is test it, and try to exercise as much of it as possible. Testing it means compiling code, and trying various different option combinations when compiling to exercise more of the code. The more code you compile the better test it is. Bootstrapping the compiler is a good correctness test. Building an entire linux distro is a better correctness test. Running the gcc regression testsuite is a good correctness test. You will also want to do performance testing. Anything you can time will work. Running standard benchmarks like SPEC is a good test. You can time how long it takes to bootstrap gcc for instance, or maybe just pick one large gcc source file, and time how long it takes to compile that file.

What other design consideration must be kept in mind while writing a new md file?

If you want to contribute it to the FSF, then you will need to worry about copyright assignments. The FSF will only accept code if they own the copyright, and it is free of any patent claims. This can be one of the hardest parts of contributing to GCC if you work at a company that hasn't dealt with FSF copyright assignment paperwork before.

Jim