PR 12828

[Jim Wilson]

Dale Johannesen wrote:
> (insn 67 66 68 0x0 (parallel [
>             (set (reg:DF 129)  (float:DF (reg:SI 128)))
>              ......
>             (clobber (mem:DF (plus:SI (reg/f:SI 114 virtual-stack-vars)
>                         (const_int 262144 [0x40000])) [0 S8 A8]))
>             ......

This seems to be a simple matter of adding CLOBBERs in addition to USEs 
to dependencies.  Search for PARALLEL in scan_loop, it should be pretty 
obvious.  You will have to work out if there are any complications from 
this change though.  Normally, a clobber doesn't prevent an insn from 
moving outside the loop.  However, a memory address inside a clobber is 
a use not a clobber, so we need to handle that.  What I would do here, 
since I am familiar with schedulers, is look at sched_analyze_1 (which 
is for writes) and handle every case where it calls sched_analyze_2 
(which is for reads).  It does this for memory addresses, 
strict_low_part, zero_extract, sign_extract, and some subregs.  Also, it 
handles set src, but that will never occur in a clobber.  Also, it 
handles a REG which is REG_EQUIV to a memory address, but it isn't clear 
if that is an issue for clobbers in loop, it probably isn't.  I think it 
unlikely that strict_low_art, zero_extract, or sign_extract would be in 
a clobber, so maybe we don't have to handle those.  The subreg case may 
also be questionable.  Clearly, we need the memory address case.

Another solution here would be to change the RTL to have a use in 
addition to, or instead of, the clobber.  This would make loop work 
correctly without change.

Another solution might be to change the RTL being generated here.  For 
instance, having a SCRATCH_SLOT rtx that works like SCRATCH except 
reload converts it into a stack slot instead of a register.  This is a 
lot more work though.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com