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: Bernd Schmidt <bernds_cb1 at t-online dot de>
- To: law at redhat dot com
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 05 May 2005 19:22:24 +0200
- 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>
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?
If I understood everything correctly, the problem could be fixed by
- detecting equivalences made by reading from memory, either directly
or through an intermediate pseudo, but not by writing to memory
- deleting all insns that only store into a pseudo that has such an
equivalence
- making ignored output reloads for all other cases where such a
pseudo is stored
Would you agree that this would fix it?
Bernd