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: Richard Biener <richard dot guenther at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: 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: Tue, 15 Mar 2016 16:16:53 +0100
- 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>
On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> 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
> forward.
So I am most worried about replicating all the complexity of types and decl
parsing for the presumably nice and small function body parser.
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.
Richard.