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: Michael Matz <matz at suse dot de>
- To: Richard Biener <richard dot guenther at gmail dot com>
- 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 17:46:12 +0100 (CET)
- 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>
Hi,
On Tue, 15 Mar 2016, Richard Biener wrote:
> 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.
Yeah, that's a fair characterization of our discussion. What I'm most
worried about with mixing C and gimple parsing are several things:
* silently accepting C-like code that actually isn't supposed to be
gimple, i.e. I fear we muddle the water by attaching something to an
existing large blob without a very clear separation
* uglifying the C parser so much that the changes become unacceptable
* Parsing gimple, but going though GENERIC; I want to directly create
GIMPLE
Separating the type/decl parsing and function body parsing would help with
all three things, and will give you a working type parser without actually
copying code around, so that's a plus.
(Of course, putting it into an existing front-end might also be less fun
than writing one from scratch, but that's not my main point :) ).
> 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.
Definitely the dumping part needs to be developed somewhat in lock-step
with the parser; the pass manager infrastructure should be started
somewhat halfway into the project, yes.
Ciao,
Michael.