This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gimplefe] [gsoc16] Gimple Front End Project
- From: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- To: Trevor Saunders <tbsaunde at tbsaunde dot org>
- Cc: Diego Novillo <dnovillo at google dot com>, David Malcolm <dmalcolm at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Prasad Ghangal <prasad dot ghangal at gmail dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>, sandeep at gcc dot gnu dot org
- Date: Wed, 9 Mar 2016 19:45:57 +0000
- Subject: Re: [gimplefe] [gsoc16] Gimple Front End Project
- Authentication-results: sourceware.org; auth=none
- References: <CAE+uiWbJ7+mY_2xYNQBTT1emXf5J+E79nK+c2cE2u1Deh8Zf=w at mail dot gmail dot com> <CAFiYyc2_93J4K7vNDZngW=5wMxUK1s+JxQo2k7TByUkDT_cz7w at mail dot gmail dot com> <1457368435 dot 9813 dot 68 dot camel at redhat dot com> <20160308002418 dot GA13433 at ball> <56DEF2F1 dot 1080900 at gmail dot com> <A7AF86B3-A2D2-429B-99B0-BDA1F345251A at gmail dot com> <1457455668 dot 9813 dot 106 dot camel at redhat dot com> <CAESRpQA-TKoQ85X9jbE7VKnCpR4oiAnH4Dsnnxmxa03oZsUjLg at mail dot gmail dot com> <1457474387 dot 9813 dot 121 dot camel at redhat dot com> <CAD_=9DTscPNw3v00HiAUh6wE5=YN1x_46vV+4uAaox40DDi3=w at mail dot gmail dot com> <20160309025043 dot GD5343 at ball>
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?
Cheers,
Manuel.