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.
