Question on aggregates and GIMPLE

[Jason Merrill]

On Tue, 8 Jun 04 22:22:20 EDT, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> However, the problem still is the large-but-nonconstant cases.  Right now,
> we'll ICE if there's an ARRAY_TYPE since temporaries are forbidden from
> having those types for reasons that have never been explained to me.  But if
> we allow that (trivial), is it still a good idea to add explicit copies of
> aggregates that could be many MB?  And then you have the types for which
> copying is not permitted.

The ICE is there largely to avoid copies of enormous aggregates.  A
transformation that requires such a temporary is almost certainly wrong.

In another thread you ask why arrays and not records.  Indeed, it might
make sense to change the check to something like aggregate_value_p.

> I hope this is readable.  The only executable line becomes:
>
> 	<MODIFY_EXPR <INDIRECT_EXPR <PARM_DECL pt2>>
> 		     <VIEW_CONVERT_EXPR <INDIRECT_REF <PARM_DECL pt1>>>>
>
> The programmer expects exactly one copy of this 1 MB array.  However, we'll
> do two since the gimplification will make a temporary for the INDIRECT_REF
> on the RHS.

<MODIFY_EXPR <INDIRECT_REF, INDIRECT_REF>> is valid GIMPLE, and shouldn't
require a temporary.  I think we're just getting confused by the
VIEW_CONVERT_EXPR.

> I "fixed" this by gimplifying VIEW_CONVERT expr that's from and to
> BLKmode into the corresponding pointer punning.

I think that may actually be the right thing to do; I'm catching up on the
VIEW_CONVERT_EXPR discussion now.

Jason