This is the mail archive of the
mailing list for the GCC project.
Re: PR rtl-optimization/15248 -- semi-latent reload bug
- From: Jeffrey A Law <law at redhat dot com>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 03 May 2005 14:11:56 -0600
- Subject: Re: PR rtl-optimization/15248 -- semi-latent reload bug
- References: <firstname.lastname@example.org> <426766CC.email@example.com> <firstname.lastname@example.org> <email@example.com> <4267F666.firstname.lastname@example.org>
- Reply-to: law at redhat dot com
On Thu, 2005-04-21 at 20:52 +0200, Bernd Schmidt wrote:
> Richard Guenther wrote:
> > I guess the real question is then, why and where do we create this SETs
> > to the pseudo (and thus the memory location) in the first place - apart
> > from the first initialization of the pseudo, of course - or does that get
> > replaced with mem = mem, too?
> Yes, that is exactly the thing that I'm not getting here. If the pseudo
> is equivalent to readonly memory, why is it ever written to?
Because in the initial insn stream the pseudo had to be initialized.
It's the replacement of the pseudo with its equivalent memory location
in the initializing insn that causes the fault.
Normally the initialization insns are removed. However, that's not the
case if the RHS of the equivalencing insn is not the equivalent
memory location (in this case the RHS of the equivalencing insn is
another pseudo which we know happens to hold the proper value).
> Maybe the
> part that creates the REG_EQUIV note sees an equivalence where there
> really isn't one?
No -- it's a valid equivalence in the sense that the two objects
always have the same value. I even verified that under the debugger :-)