[gimplefe] [gsoc16] Gimple Front End Project

[Andrew MacLeod]

On 03/07/2016 11:33 AM, David Malcolm wrote:
>>
>>
>>
>>
>> So for testing specific passes, I'd much rather have an input format
>> for testing individual passes that:
>>    * can be easily generated by GCC from real test cases
>>    * ability to turn into unit tests, which implies:
>>      * human-readable and editable
>>    * compatibility and stability: can load gcc 7 test cases into gcc 8;
>> have e.g. gcc 6 generate test cases
>>    * roundtrippable: can load the format, then save out the IR, and get
>> the same file, for at least some subset of the format (consider e.g.
>> location data: explicit location data can be roundtripped, implicit
>> location data not so much).
>>
>> ...which suggests that we'd want to use gimple dumps as the input
>> format to a test framework - which leads naturally to the idea of a
>> gimple frontend.


We already read and write gimple IL in LTO, we just do it in binary 
form.  I think the kind of effort you are talking about here is best 
placed in attaching a gimple parser to LTO, thus giving LTO the ability 
to read and write textual gimple as well as the current binary form.     
The current dump format could in theory be a starting point, but its 
clearly missing hunks of stuff.  there is probably a better representation.

LTO already knows all the bits required to reconstruct gimple. The 
definition of the textual representation can make intelligent choices 
about defaults so that you don't have to specify every single bit in the 
textual form that the binary form requires.  ThIs seems far easier to me 
than starting with the incomplete form that the current dumps generate 
and trying to discover what other bits need to be added to properly 
reconstruct the IL.  I think its hard to get a lot of the subtle things 
right.    I also think the scope of defining and reading/writing should 
be relatively manageable.  We can optimize the details once its working.

It would also be very useful then  to have LTO enhanced so that it can 
read and write before or after any pass...  Then we can unit test any 
pass by injecting the IL immediately before the pass..  No jumping 
through any hoops to make sure the pass you care about sees the exact IL 
you want..   That is also a good proof that the LTO form (both binary 
and text) does fully represent gimple.  We can also use this output as 
our debugging dumps and archive the current dumper.

As gimple changes and evolves the result is only one place to worry 
about for reading and writing...  and as we progress (slowly) towards 
uncoupling the middle/backend from the front ends, we'd have a single 
well defined "front end" for gimple that accepts binary or text.

Andrew