Re: Regression for trunk on i686-pc-linux-gnu

[Diego Novillo <dnovillo at redhat dot com>]

On Tue, 2004-07-27 at 16:47, Richard Kenner wrote:
>     Wrong.  You added INDIRECT_REF with
> 
>     2004-06-21  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
>     [ ... ]
>             * tree-gimple.c (is_gimple_addr_expr_arg): Add ARRAY_RANGE_REF
>             and INDIRECT_REF.
>     [ ... ]
> 
>     IMO, that change is incorrect and should be reverted.
> 
> By "original", I meant in terms of the failure of this test.
> 
Why exactly did allowing INDIRECT_REF in is_gimple_addr_expr_arg make
this test pass?

> It's very much the case that the folding occurs if INDIRECT_REF is
> allowed by that function and not if it doesn't.
> 
>     Taking the address of an pointer dereference makes no sense.  Why
>     do you think it does?
> 
> It occurs in lots of places.
>
I don't doubt that.  What I doubt is whether it's reasonable at all.
If this only occurs during gimplification, why not just strip
INDIRECT_REF when you build the call to memcpy?

The reason why we support folding of *&VAR is because it exposes
optimization opportunities.  I see no such advantage here.


> For example, if I have a MODIFY_EXPR of
> variable size with one operand being an INDIRECT_REF, we gimplify that
> to be a call to memcpy with the addresses of each side of the MODIFY_EXPR.
> That means we pass an <ADDR_EXPR <INDIRECT_REF ...>> to the CALL_EXPR.
>
> We can't break that up during gimplification because the INDIRECT_REF's
> type is variable-sized and even if we could allocate the proper temporary,
> it would cause infinite recursion (via the above).
>
Why not just pass the operand to INDIRECT_REF?  After all, it is a
pointer, isn't it?


Diego.