PR rtl-optimization/15248 -- semi-latent reload bug

Jeffrey A Law law@redhat.com
Fri May 6 17:29:00 GMT 2005


On Fri, 2005-05-06 at 19:22 +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> > 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.
> 
> Could be done by forcing an output reload that doesn't get stored 
> anywhere.  We have machinery to do this for regs with REG_UNUSED notes etc.
That's beyond my knowledge of reload.  If you can cobble up some code
I'm happy to give it a spin and poke at it some more.

jeff




More information about the Gcc-patches mailing list