This is the mail archive of the
mailing list for the GCC project.
Re: [patch 3/4] Separate gimple.[ch] and gimplify.[ch] - front end files
- From: Diego Novillo <dnovillo at google dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Richard Biener <richard dot guenther at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Thu, 14 Nov 2013 10:37:23 -0500
- Subject: Re: [patch 3/4] Separate gimple.[ch] and gimplify.[ch] - front end files
- Authentication-results: sourceware.org; auth=none
- References: <5281460E dot 1070001 at redhat dot com> <52814709 dot 6080904 at redhat dot com> <CAFiYyc3xFo3KzNv8QurvoBW-Ef9=0FdbgoC5Z=U=zACPPb90gg at mail dot gmail dot com> <528388D1 dot 7050808 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1311141606320 dot 11100 at wotan dot suse dot de> <5284ED7A dot 8020805 at redhat dot com>
On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod <firstname.lastname@example.org> wrote:
> On 11/14/2013 10:26 AM, Michael Matz wrote:
>> On Wed, 13 Nov 2013, Andrew MacLeod wrote:
>>> There needs to be a place which has gimple componentry that is not
>>> related to or require a statement. gimple.h is becoming the home for
>>> just 0gimple statements. There are 3 (for the moment) major classes of
>>> things that are in statements and are also used by other parts of the
>>> compiler .. Types, Decls, and Expressions.
>> E.g. there won't ever be something like a gimple arithmetic addition
>> expression (or I hope there never will be). It's always a gimple
>> statement that assigns the addition result somewhere. Even the
>> non-singleton objects don't exist in isolation, they're always part of
>> some action (i.e. statement) to operate on those objects.
>> That's why I think talking about a gimple expression as if they were
>> somehow some stand-alone concept is fairly confusing, and introducing it
>> now as if it would somewhen exist would lead to going down some inferior
>> design paths.
> Well, for gimple expressions I was thinking more about the addressing
> expressions we currently leave as trees... MEM stuff... that where most of
> the remaining 'expressions' are I guess, so perhaps gimple-addressing is a
> better term...
> in any case, it refers mostly to the parts of trees which are tcc_expression
> and are not subsumed by gimple_statement contructs. So I use expression for
> lack of a better term since I don't know what exact uses there are yet.
I think we'll end up with a hierarchy that will have some generic
"value" at its base, with constants, symbols, aggregates, arrays,
memrefs, etc as children. But perhaps we can wait until we have a
better idea of how we want it to look like.