[gimplefe] [gsoc16] Gimple Front End Project

[Michael Matz]

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.