This is the mail archive of the gcc-patches@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]

Re: fix for execute/950511-1 failure on ppc-eabi


> Date: Mon, 11 Sep 2000 17:02:18 -0400 (EDT)
> From: John Wehle <john@feith.com>
> CC: gcc-patches@gcc.gnu.org
> 
> > (reg/v:SI 83)
> > and
> > (addressof:SI (reg/v:DI 84) 82 0x30037480)
> > don't qualify as rtx_equal_for_memref_p.
> > 
> > Note that the SET might be conditionally executed.
> 
> I was mistaking thinking that alias analysis had noticed that
> (reg/v:SI 83) had been set to the addressof (aka canon_rtx
> and reg_known_value).

You can't be sure this will always happen.  canon_rtx will only notice
this if the reg is _always_ equal to the addressof; but we care even
if it is _sometimes_ equal.

>  I'll get the simulator running and
> play with this some more.  It'd be nice to notice that an
> addressoff doesn't conflict with a stack variable.  BTW,
> I noticed that you changed things so that BLKmode addressofs
> don't conflict.
> 
>   1) When does a BLKmode addressof get created?

I have no idea.  I'm not sure it's legal.  If it is legal, though,
it would look like

(addressof:SI (reg:BLK 234))

and clearly

(addressof:SI (reg:BLK 234))
(addressof:SI (reg:BLK 235))

must be different addresses, and MEM references to them can only be
references to parts of registers 234 and 235 respectively, and so must
be different.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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