Thanks everyone for suggestions, Here is my updated proposal. I know its too late but can somebody review it?
https://drive.google.com/file/d/0B2S9OoautWxsbVBkWDY3VDNkdGc/view?usp=sharing On 25 March 2016 at 08:46, Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> wrote: > On 25 March 2016 at 01:15, Prasad Ghangal <prasad.ghan...@gmail.com> wrote: >> On 24 March 2016 at 19:01, Richard Biener <richard.guent...@gmail.com> wrote: >>> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal >>> <prasad.ghan...@gmail.com> wrote: >>>> Hi! >>>> >>>> I have attached my gsoc proposal, please review it. Let me know if I >>>> have missed or misunderstood anything >>> >>> Please re-word the Abstract, it is really weird to read - I suggest to drop >>> any notion of RTL or "back end" and somehow mention that unit testing >>> is why "we want make changes in GIMPLE". Also stopping compilation >>> isn't in the scope of the project (and while maybe a nice thing to have >>> to do less work it is not a requirement for unit testing). >>> >>> Thus Project Goals are only unit testing (which includes what you call >>> start/stop compilation). >>> >>> During the discussion in the last comments we agreed on re-using the >>> C frontend for decls and types only and implement a completely separate >>> parser for the function bodies so the frontend can also emit GIMPLE >>> directly. >>> >>> Thus I'd scrap 4.A)/B) and instead write about >>> >>> 4. >>> A) Define GIMPLE syntax >>> Provide GIMPLE dumps with enough information to parse GIMPLE and >>> change them according to agreed on GIMPLE syntax >> >> Little confused here. Don't we need to change syntax first and then >> develop grammar to parse it? > Well the purpose of grammar is to define the syntax. > We would need to first define a grammar for GIMPLE and then implement > a (predictive) parser > that parses GIMPLE input according to our grammar and emits GIMPLE IR. > contrived eg: > stmt_list: stmt stmt_list_1 > stmt_list_1: stmt stmt_list_1 | epsilon > stmt: lvalue_operand '=' assign_stmt > | 'if' cond_stmt > assign_stmt: operand | operator operand | operand operator operand > operand: INT | lvalue_operand > lvalue_operand: ID > operator: '+' > > As pointed out by Richard, dumps could be modified later to adjust to > GIMPLE syntax, > initially you could write test-cases by hand. > > Thanks, > Prathamesh >> >>> >>> B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser >>> >>> For the suggested timeline I think that it is important for the "get >>> basic stuff working" >>> part to have all pieces of the project prototyped, including the pass >>> manager >>> support. Otherwise there is no way to fully test part of the >>> implementation. >>> I'd say modifying the gimple dumps can be done last as you can always write >>> testcases manually. >>> >>> I realize that the student application deadline is tomorrow. >>> >>> Richard. >>> >>> >>> >>>> >>>> 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
