Re: [gimplefe] [gsoc16] Gimple Front End Project

[Prasad Ghangal <prasad dot ghangal at gmail dot com>]

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.kulkarni@linaro.org> wrote:
> On 25 March 2016 at 01:15, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>> On 24 March 2016 at 19:01, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
>>> <prasad.ghangal@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.guenther@gmail.com> wrote:
>>>>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>>>>> <prathamesh.kulkarni@linaro.org> wrote:
>>>>>> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>>>>>> <prasad.ghangal@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 <tbsaunde@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.guenther@gmail.com> wrote:
>>>>>>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>>>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>>>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@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