Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
> > 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.
Well, I can precisely name you the set of things you mean then, and I
wouldn't call any of them expressions (all of them either represent a
(sub)object or a statement of fact, not a computation (except as part of
how to get at the specified object)):
CODE_CLASS == tcc_reference
: COMPONENT_REF, BIT_FIELD_REF, ARRAY_REF, ARRAY_RANGE_REF,
REALPART_EXPR, IMAGPART_EXPR, VIEW_CONVERT_EXPR, INDIRECT_REF,
TARGET_MEM_REF, MEM_REF
CODE ==
: CONSTRUCTOR, OBJ_TYPE_REF, ASSERT_EXPR, ADDR_EXPR, WITH_SIZE_EXPR
The rest is the trivial SSA_NAME, tcc_constant and tcc_declaration, what I
called singletons.
Most of the codes above have a shallow one- or two-level structure in what
they operate on, or can be made so by some more lowering. A few of them
can contain arbitrarily deep recursive structures (but not of all possible
trees), and I think that's the only thing that would remain if the above
would be better melded into serveral new statement types. That's of
course also the difficult part to get sensibly rid of, because the
recursive structure lends itself to something that terribly looks like
'tree'.
I think if following through with the whole plan there would (and should)
be nothing remaining that could be called a gimple expression.
Ciao,
Michael.
