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