On 11/14/2013 10:37 AM, Diego Novillo wrote:
On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod <amacl...@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.
That is pretty much what my prototypes at th cauldron had... I just
hadn't fit expressions into it yet... so just left the term. but that
why it is lumped in with decls and types... things that will have their
tree replaced. In any case... thats all to come...
Andrew
