This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]