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
