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

[Richard Biener <richard dot guenther at gmail dot com>]

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.