This is the mail archive of the
gcc-patches@gcc.gnu.org
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: Fri, 06 May 2005 10:46:10 -0600
- Subject: Re: PR rtl-optimization/15248 -- semi-latent reload bug
- References: <1114020137.5853.17.camel@localhost.localdomain> <426766CC.8040708@t-online.de> <1114091206.5853.44.camel@localhost.localdomain> <84fc9c0005042106581ad3a9b4@mail.gmail.com> <4267F666.8070003@t-online.de> <1115151116.23400.219.camel@localhost.localdomain> <427A5650.1010509@t-online.de>
- Reply-to: law at redhat dot com
On Thu, 2005-05-05 at 19:22 +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> > On Thu, 2005-04-21 at 20:52 +0200, Bernd Schmidt wrote:
> >
> >>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).
>
> Ok. Still, we should be able to delete the initializing insn in this
> case if it has no other side effects, correct?
Assuming you can find them all and safely eliminate the store side
affect. Again, consider that the store might be buried inside a
PARALLEL. That's a non-trivial problem.
jeff