Re: [gimplefe] [gsoc16] Gimple Front End Project

[Andrew MacLeod <amacleod@redhat.com>]

On 03/09/2016 10:47 AM, Richard Biener wrote:
> On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
>> 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.
> So I chose to reply to this one (and will refrain from replying to other but try
> to address comments there).
>
> First, while the LTO approach works it's quite overkill in the details
> it "dumps"
> and thus it's too closely tied to our internal bits which means testcases will
> bitrot too quickly for the number one goal of having human
> maintainable testcases.
>

The binary form is clearly tied to a lot of implementation bits, but I 
would think a lot of those bits have a reasonable default value that 
wouldn't have to be explicitly expressed in textual form, but could be 
if so desired via attributes, tags, new keywords,  or whatever.

  The current dumps are C-like and could work as a decent starting point 
for textual gimple input/output.   From the LTO vantage point, you can 
see all the other bits which might need to be expressed, and can get to 
them later.   That is "merely" the follow on hard work of flushing out 
the details :-)

I'd just hate to see a lot of work go into it and have it made 
completely redundant in a  few years by the presence of a new lto 
reader/writer than can do the same job.  Of course that's still blue-sky 
stuff and could never happen.

No matter what approach is taken, it would be good to keep in mind the 
possibility of enhancing it to be the LTO text reader so that decisions 
aren't made which make that impractical..    I don't think its on my hit 
list for a while yet... but it would be really  nice to be able to 
leverage any work that is done in this direction.  It would be ideal to 
be able to simply add enhancements to whatever we have to provide the 
rest of what LTO requires to be a complete reader/writer.

Andrew