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