Hi! Sorry for the late reply.
I was observing gimple dumps and my initial findings are, to parse gimple, we have to add support for following components to C FE *basic blocks *gimple labels and goto *gimple phi functions iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4) *gimple switch switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>> *gimple exception handling *openmp functions like main._omp_fn.0 (void * .omp_data_i) Please correct me if I am wrong. Also point out if I am missing anything On 18 March 2016 at 14:53, Richard Biener <richard.guent...@gmail.com> wrote: > 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. -- Thanks and Regards, Prasad Ghangal