Question on aggregates and GIMPLE

[Richard Henderson]

On Tue, Jun 08, 2004 at 07:00:21PM -0400, Richard Kenner wrote:
> Suppose I have a MODIFY_EXPR whose RHS is a VIEW_CONVERT_EXPR of some
> aggregate type (say a RECORD_TYPE) whose operand is an INDIRECT_REF.
> If the size of the type is variable, the MODIFY_EXPR will be converted
> to a call to built in memcpy.  But it it's fixed size, we'll end up
> making a temporary for the RHS or the INDIRECT_REF.

Well, unless you've done something wrt your most curious use of
VIEW_CONVERT_EXPR, then yes we will make a temporary.

If you've changed things to arrange for it to be considered
is_gimple_lvalue in the gimple grammer, then no, you shouldn't
need a temporary.  Instead it'll remain the rhs of a MODIFY_EXPR
which will be expanded to memcpy by expand_expr.

Are you going to start posting patches for these sorts of gimple
extensions so that we can review them?

> Does the same transformation for variable-sized types have to be done
> for comparisons of aggregate objects too?  I don't see any code to
> call built in memcmp.  And then you have the above issue.

What the hell does a comparison of an aggregate mean?  I suppose we
could gimplify it to memcmp, but since I suspect no one else thinks
such things are possible, this could as well be a front-end issue.

> Also, the call when converting to the memcpy call is missing the
> use of SUBSTITUTE_EXPR_IN_PLACEHOLDER when getting the size: there
> are routines elsewhere in the compiler that do it right and should
> be called instead (such as expr_size).
> 
> What's the best way to deal with these issues?

Given that no one other than you knows what a PLACEHOLDER_EXPR is,
it's up to you to figure out where we're missing such things and
replicate expr_size and its ilk to work on trees in gimplify.c.

And since no one other than Ada uses such things, I consider this
part and parcel with porting the Ada front end.


r~