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
