Re: More on c-gimplify.c:gimplify_decl_stmt

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    You'll have to give a significantly more precise description than this.  

Of course.  I don't claim to have a solution to the problem, especially
because I apparently don't understand the issues well enough.

    As for the third argument, I don't see how it helps.  

The idea was to be able to use it to reason on things such as the array
reference and get aliasing information.

    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.

Indeed that's the hard question and the one I don't know the answer to.

That's why my initial feeling is that the tree optimizers should *not*
attempt to optimize anything related to the type fields (sizes and
positions).  They're constants and don't need optimization.  It seems to me
that putting them into the computation just makes things more complex.

I still don't see the problem with simply marking the relevant variables as
implicitly used when a variable of a type is used and leaving it at that
(except for PLACEHOLDER_EXPR, which is, of course, a mess).  Why get them
involved in the optimization?  That's what the RTL optimizers will be for:
let the tree optimizers concentrate on high-level stuff.

    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.

We have a function that computes 3 from 2, so that's not needed, but this is
essentially my proposal, but without the structuring information.  However,
we need that information for aliasing and loop information.

Another problem with doing this early is that you can't scalarize fields that
are at variable offsets and I see no reason to exclude that.