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

[Richard Biener <richard dot guenther at gmail dot com>]

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

    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