This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Regression for trunk on i686-pc-linux-gnu
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: dnovillo at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 27 Jul 04 17:50:20 EDT
- Subject: Re: Regression for trunk on i686-pc-linux-gnu
Why exactly did allowing INDIRECT_REF in is_gimple_addr_expr_arg make
this test pass?
I have no clue. I haven't tried to analyze that yet and am not sure where
to look.
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?
Mostly because it means looking for it. And you might have something
like a VIEW_CONVERT_EXPR in between. So it's not a trivial test and
it would have to be in a number of places.
My feeling would be to standardize this with some common code, but
even then you need to allow INDIRECT_REF in something that's
going to be *fed* to the common code, and that's my recollection of
what's happening here.
The reason why we support folding of *&VAR is because it exposes
optimization opportunities. I see no such advantage here.
I don't follow. If folding *&VAR to VAR creates optimization opportunities,
doesn't folding &*VAR to VAR do exactly the same?
Why not just pass the operand to INDIRECT_REF? After all, it is a
pointer, isn't it?
That's what ends up happening, but it's this folding that makes it happen.