This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on aggregates and GIMPLE
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 09 Jun 2004 08:08:18 -0400
- Subject: Re: Question on aggregates and GIMPLE
- Organization: Red Hat Canada
- References: <10406090222.AA26255@vlsi1.ultra.nyu.edu>
On Tue, 2004-06-08 at 22:22, 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.
>
You answered your own question. GIMPLE is a scalar language, so it's
never necessary for the compiler to create intermediate arrays to hold
copies of other arrays. Think of it as a target that only has one block
move operations: bitwise copy of aggregates of a fixed size.
If we decide to support matrix operations for the sake of the
vectorizer, we will need to evaluate what that means in terms of
temporaries. But that's a very specific case. It doesn't seem to me
that any of the Ada variable-sized aggregates could benefit from this,
but I don't know for certain.
> with unchecked_conversion;
> package tuc is
> type t1 is array (1...250000) of integer;
> type t2 is array (1...250000) of float;
> function uc is new unchecked_conversion (t1, t2);
> type pt1 is access all t1;
> type pt2 is access all t2;
> procedure cpy (p1: pt1; p2: pt2);
> end tuc;
> package body tuc is
> procedure cpy (p1: pt1; p2: pt2);
> begin
> pt2.all := uc (pt1.all);
> end cpy;
> end tuc;
>
> 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.
>
Really? VIEW_CONVERT_EXPR <> is a valid GIMPLE RHS. Show me the
gimplified form of this function?
Out of that we ought to generate a VDEF (shortly, V_MUST_DEF) for *pt2
and a VUSE for *pt1.
Diego.