This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix for execute/950511-1 failure on ppc-eabi
- To: john at feith dot com
- Subject: Re: fix for execute/950511-1 failure on ppc-eabi
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Mon, 11 Sep 2000 14:15:48 -0700
- CC: gcc-patches at gcc dot gnu dot org
- References: <200009112102.RAA09782@jwlab.FEITH.COM>
> 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>