This is the mail archive of the
mailing list for the GCC project.
Re: [gimplefe] [gsoc16] Gimple Front End Project
- From: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Michael Matz <matz at suse dot de>, Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>, Trevor Saunders <tbsaunde at tbsaunde dot org>, Diego Novillo <dnovillo at google dot com>, David Malcolm <dmalcolm at redhat 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: Fri, 18 Mar 2016 11:25:10 +0530
- 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> <CAESRpQCwWDcTembu1ZRv25zAmi1ZdN4nFZpJWTiO4a4-Xc8AVA at mail dot gmail dot com> <CAFiYyc3N9i6VV8XCXjhz6EMs1g7UPvEYKuT8WP3qoKU5cadySg at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1603141821110 dot 20277 at wotan dot suse dot de> <CAFiYyc3z=3CbhChRruWP11+YCRKpESjJEu9rSK=5ScX-6-UMrg at mail dot gmail dot com>
On 15 March 2016 at 20:46, Richard Biener <email@example.com> wrote:
> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <firstname.lastname@example.org> wrote:
>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>> 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).
>> I think it's wrong to try to shoehorn the gimple FE into the C FE. C is
>> fundamentally different from gimple and you'd have to sprinkle
>> gimple_dialect_p() all over the place, and maintaining that while
>> developing future C improvements will turn out to be much work. Some
>> differences of C and gimple:
>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>> * C has type promotions, gimple is explicit
>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>> lookup is much more complicated
>> * C doesn't have exceptions
>> * C doesn't have class types, gimple has
>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>> * C doesn't have self-referential types
>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>> gimplifier and again would feed gimple directly into the passes)
>> I really don't think changing the C FE to accept gimple is a useful way
> So I am most worried about replicating all the complexity of types and decl
> parsing for the presumably nice and small function body parser.
Um would it be a good idea if we separate "gimple" functions from
regular C functions,
say by annotating the function definition with "gimple" attribute ?
A "gimple" function should contain only gimple stmts and not C.
// local decls/initializers in C
// GIMPLE body
Or perhaps we could add a new keyword "gimple" telling C FE that this
is a GIMPLE function.
My intention is that we could reuse C FE for parsing types and decls
(which I suppose is the primary
motivation behind reusing C FE) and avoid mixing C statements with
GIMPLE by having a separate
GIMPLE parser for parsing GIMPLE functions.
(I suppose the GIMPLE function parser would need to do minimal parsing
of decls/types to recognize
the input is a declaration and call C parsing routines for parsing the
When C front-end is invoked with -fgimple it should probably only
accept functions marked as "gimple".
Does this sound reasonable ?
> In private discussion we somewhat agreed (Micha - correct me ;)) that
> iff the GIMPLE FE would replace the C FE function body parsing
> completely (re-using name lookup infrastructure of course) and iff the
> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
> then "re-using" the C FE would be a way to greatly speed up success.
> The other half of the project would then be to change the pass manager
> to do something sensible with the produced GIMPLE as well as making
> our dumps parseable by the GIMPLE FE.