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

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Mar 10, 2016 at 11:46 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 8:45 PM, Manuel LÃpez-IbÃÃez
> <lopezibanez@gmail.com> wrote:
>> On 9 March 2016 at 02:50, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>> On Tue, Mar 08, 2016 at 05:12:56PM -0500, Diego Novillo wrote:
>>>> This way, implementing a library that supports dealing with GIMPLE
>>>> becomes much simpler.  This provides a nice foundation for all kinds
>>>> of gimple-oriented tooling in the future.
>>>
>>> Well, one nice thing about choosing a subset of C as your textual
>>> representation of gimple is that all the tools that deal with C already
>>> can deal with it, and so you won't really need separate tools for gimple
>>> (that would be my theory anyway).
>>
>> What tools available for C would be useful for working with gimple IR?
>> Diego means tools like those available for modifying, compiling and
>> verifying LLVM IR and its bytecode representation. Things like
>> http://www.cis.upenn.edu/~stevez/vellvm/ and
>> http://blog.regehr.org/archives/1170 No such thing is available for C
>> (nor GIMPLE), because they are not a well-defined IR
>> (http://lambda-the-ultimate.org/node/715#comment-6526).
>>
>> If the gimple IR were a strict subset of GNU C, then by all means
>> let's re-use the C FE. However, gimple encodes things that are
>> necessary for other languages but are not C. C++ gimple dumps have
>> try-finally. Fortran dumps use explicit parentheses "((x))". Surely,
>> Ada adds its own quirks to gimple. You can probably represent all this
>> with a C-looking language plus some large number of new __builtins_
>> and __attributes__. At that point you will end up with something that
>> is neither a super-set, nor a sub-set of any of the many C variants
>> already supported by the C parser. Thus, one would need to
>> significantly hack the existing C parser to correctly parse this
>> C-looking language, while not breaking any of the things supported by
>> the C parser, nor accepting anything not supported by gnu/std C.
>>
>> Should the gimple-C parser support promotion rules? If GIMPLE is
>> three-adresses-based, why support expressions with more than two
>> operands at all? If the dumped IR should be sufficient to stop
>> compilation, dump, reload, and continue, then how to represent
>> language-specific tree codes that survive until RTL? (perhaps FE trees
>> leaking into RTL got fixed already and I'm outdated here). What about
>> preserving the original source locations? And debug info? All that
>> would need to be handled by a gcc equivalent of LLVM's opt tool. How
>> is all that going to be represented in gimple-C?
>
> Well.  I'd like to have a convenient way to write unit-tests for
> GIMPLE (SSA) passes
> that work good enough which means I have to approximate the GIMPLE IL fed into a
> GIMPLE pass so that I can reproduce a critical situation and keep that stable
> over the evolution of GCC (and passes before that pass).
>
> The most simplistic and pragmatic way was the proposal intruducing -Otest
> https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01879.html
>
> I'd like to have "proper" pass manager modifications to make that work better.
>
> Then I'd like to be able to re-construct SSA without jumping through hoops
> (usually you can get close but if you require copies propagated in a special
> way you are basically lost for example).
>
> Thus my proposal to make the GSoC student attack the unit-testing problem
> by doing modifications to the pass manager and "extending" an existing
> frontend (C for simplicity).
>
> It's true that in the ideal world a "GIMPLE frontend" has to work differently
> but then to get a 100% GIMPLE frontend you indeed arrive at what LTO
> does and then I agree we should attack that from the LTO side and not
> develop another thing besides it.  But this is a _much_ larger task and
> I don't see anyone finishing that.  Also keep in mind that the LTO side will
> likely simplify a lot by stripping out the ability to stream things that are
> only required for debug information (I hopefully will finish LTO early debug
> for GCC 7).
>
> So - can we please somehow focus on the original question about a
> GSoC project around the "GIMPLE frontend"?  Of course you now can
> take Davids promise of spending some development time on this
> into consideration.  Try drafting something that can be reasonably
> accomplished with giving us something to actually use in the GCC 7
> timeframe.

Oh, and rather than trying to define semantics of GIMPLE to write a
frontend I'd write the reverse first - a "backend" (aka dumper) plus a
simulator.  During that effort you can then also do the specification part.
You'd produce bytecode plus a textual form.

Note that if the textual form is too nice people may view it as a loop-hole
into our runtime license exception.

Richard.

> Thanks,
> Richard.
>
>> Cheers,
>>
>> Manuel.