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

[Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>]

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

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)
When C front-end is invoked with -fgimple it should probably only
accept functions marked as "gimple".
Does this sound reasonable ?

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.