On 15 March 2016 at 20:46, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <m...@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. 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. eg: __attribute__((gimple)) void foo(void) { // 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 whole decl) When C front-end is invoked with -fgimple it should probably only accept functions marked as "gimple". Does this sound reasonable ? Thanks, Prathamesh > > 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.