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

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

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.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