Hi! Here is the link my gsoc proposal, please review it. Let me know if I have missed or misunderstood anything
https://drive.google.com/file/d/0B2S9OoautWxsbVBkWDY3VDNkdGc/view Thanks and Regards, Prasad Ghangal On 22 March 2016 at 19:23, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni > <prathamesh.kulka...@linaro.org> wrote: >> On 22 March 2016 at 16:26, Richard Biener <richard.guent...@gmail.com> wrote: >>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal >>> <prasad.ghan...@gmail.com> wrote: >>>> Hi! >>>> >>>> How exactly can we achieve start stop compilation on specific pass (ie >>>> run single pass on input)? >>>> >>>> eg. $cgimple -ftree-copyrename foo.c >>>> >>>> should produce optimization result of -ftree-copyrename pass on foo.c input >>> >>> You need pass manager support and annotate each function with information >>> on what passes should be run (in which order even?). I think for the GSoC >>> project specifying a starting pass for each function via the source, like >>> >>> __GIMPLE (tree-copyrename) void foo (void) >>> { >>> ... >>> } >>> >>> and hacking the pass manager to honor that is enough. >> Um would annotating each function with pass order work for ipa passes too ? > > There is no single point of execution for an IPA pass so no - you can > tag it with > one of the umbrella passes I guess. I suppose we'd need some magic "phase" > tags for this, like simply "IPA". You then need to enable/disable IPA passes > you want to run. > > Richard. > >> Thanks, >> Prathamesh >>> >>> Richard. >>> >>>> >>>> >>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsau...@tbsaunde.org> wrote: >>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote: >>>>>> 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 >>>>> >>>>> I'd think you can probably make these enough like C labels that you >>>>> don't need to do anything special in the C fe to parse these. Just >>>>> removing the < and > gets you pretty close is that it? >>>>> >>>>>> *gimple labels and goto >>>>> >>>>> Similar I think. >>>>> >>>>>> *gimple phi functions >>>>>> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4) >>>>> >>>>> yesI think you need to add something here. I think you can do it as a >>>>> builtin type function that expects its arguments to be labels or names >>>>> of variables. >>>>> >>>>>> *gimple switch >>>>>> switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>> >>>>> >>>>> I'd think we could make this more C like too. >>>>> >>>>>> *gimple exception handling >>>>> >>>>> yeah, though note exceptions are lowered pretty quickly so supporting >>>>> them with the explicit exception syntax probably isn't particularly >>>>> important. >>>>> >>>>>> *openmp functions like >>>>>> main._omp_fn.0 (void * .omp_data_i) >>>>> >>>>> I'd think you'd want to change the duping of this some to make it easier >>>>> to tell from struct.some.member. >>>>> >>>>>> Please correct me if I am wrong. Also point out if I am missing anything >>>>> >>>>> I think you might need to do something about variable names? >>>>> >>>>> Trev >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> Prasad Ghangal
