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