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