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: 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>
- Date: Tue, 27 Jul 2004 18:47:10 -0400
- Subject: Re: Regression for trunk on i686-pc-linux-gnu
- Organization: Red Hat Canada
- References: <10407272150.AA25883@vlsi1.ultra.nyu.edu>
On Tue, 2004-07-27 at 17:50, Richard Kenner wrote:
> I have no clue. I haven't tried to analyze that yet and am not sure where
> to look.
>
It's easy:
$ cc1.clean -fdump-tree-all-vops
$ mv *.c.t* 00good
$ cc1.busted -fdump-tree-all-vops
$ mv *.c.t* 00bad
Start diffing 00bad/ vs 00good/
> 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.
>
Why not call get_base_address? That's the standard way of getting the
pointer out of an INDIRECT_REF. Assuming that the INDIRECT_REF is
already gimplified, of course.
> 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?
>
No. In *&VAR we had a variable whose address was being taken. After
folding it to 'VAR', we now have a GIMPLE register. That's not the case
with &*PTR.
> 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.
>
Why can't you use get_base_address and feed that to memcpy?
I still think that it is a mistake adding ADDR_EXPR <INDIRECT_REF <>> to
GIMPLE. This needs to be solved in the front end. By allowing it in
GIMPLE we are exposing ourselves to trouble.
We don't explicitly accept *&VAR in GIMPLE, either. It may be
temporarily produced by constant propagation, but it is squashed by
fold_stmt before it gets a chance to propagate further.
I would welcome a true GIMPLE grammar verifier at this point. I think
we are allowing things in the grammar that we shouldn't. Right now the
closest thing we have to a verifier is get_expr_operands.
Diego.