Re: More on c-gimplify.c:gimplify_decl_stmt

[Richard Henderson <rth at redhat dot com>]

On Sun, Jun 06, 2004 at 06:03:37PM -0400, Richard Kenner wrote:
> We have a node called something like REFEREFENCE_EXPR.  It has three
> operands.  The first is what get_inner_reference returns for the inner
> value.  It's an aggregate and a GIMPLE object.  The second operand is
> the number of bytes offset from the value.  It's been gimplified in
> the usual manner.  Since it was what get_inner_reference returns, all
> such things as PLACEHOLDER_EXPRs have been taken care of.  The third
> operand is the original tree of _REF operations, so that things like
> loop optimizers can deduce things about the loops in question.

You'll have to give a significantly more precise description than
this.  The first two arguments make it sound like a variant of
BIT_FIELD_EXPR that operates on bytes instead of bits.

As for the third argument, I don't see how it helps.  You've got
to remember that optimizers between gimplification and loop stuff
need to be able to keep this field up-to-date as indicies get
SSA_NAMES, get copy-propagated, DCEd, etc.  We *might* be able
to do enough to give the distance vectors an idea of how far apart
two references are, but I doubt we'd be able to preserve enough to
manipulate it in any interesting way during strength reduction.

I might could see a use for a GENERAL_COMPONENT_REF node that
contained

	0	Aggregate being referenced
	1	Byte offset from beginning of aggregate
	2	Bit offset from byte offset
	3	Max power of 2 byte is known to contain.

Which would more or less be able to merge COMPONENT_REF/ARRAY_REF
with VIEW_CONVERT_EXPR.  If we allow bit to be variable, that
allows easy implementation of bit arrays.


r~