This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]