This is the mail archive of the gcc-patches@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: [patch 3/4] Separate gimple.[ch] and gimplify.[ch] - front end files


On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 11/14/2013 10:26 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> 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.


Diego.


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