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

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

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.

Thanks,
Richard.

> Cheers,
>
> Manuel.