This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]