Re: [gimplefe] [gsoc16] Gimple Front End Project

[Prasad Ghangal <prasad dot ghangal at gmail dot com>]

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
*gimple labels and goto
*gimple phi functions
        iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
*gimple switch
        switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>

*gimple exception handling

*openmp functions like
        main._omp_fn.0 (void * .omp_data_i)

Please correct me if I am wrong. Also point out if I am missing anything




On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
> On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
>> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@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