On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> wrote: > 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 ?
Yes, that was my idea. > 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. Though instead of an attribute I would indeed use a new keyword (as you can't really ignore the attribute and it should be an error with compilers not knowing it). Thus sth like void foo (void) __GIMPLE { } as it's also kind-of a "definition" specifier rather than a declaration specifier. > > 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) Yes, eventually the C frontend provides routines that can be used to tentatively parse declarations / types used in the function. > When C front-end is invoked with -fgimple it should probably only > accept functions marked as "gimple". > Does this sound reasonable ? I think -fgimple would only enable recognizing the __GIMPLE keyword, I wouldn't change all defs to GIMPLE with it. Richard. > 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.