Re: Loop invariant code corrupting xstormy16 insn

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

> >  I think that I have found a small bug in the loop invariant code.
> >  The problem is exhibited when building newlib for the xstormy16-elf
> >  toolchain although it may happen with other targets as well.  The
> >  problem occurs when an insn contains an r-value use of a register
> >  that is going to hoisted as well as a clobber of that register, like
> >  this:
> >
> >    (parallel [
> >              (set (pc)
> >                   (if_then_else (lt:SI (reg:SI 45)    <---
> >                                        (reg:SI 26))
> >                                 (label_ref:HI 129)
> >                                 (pc)))
> >              (clobber (reg:SI 45))                    <-- must be  
> >the same
> >              (clobber (scratch:BI))
> >              ])
> >
> >  The important point here is that the register referenced in the
> >  first clobber must match the register used as the first argument of
> >  the condition operation.  (This comes from the "ineqbranchsi"
> >  pattern in the xstormy16 machine description).
> >
> >  The problem is that the loop-invariant optimization was deciding
> >  that (reg:SI 45) could be hoisted out of the loop, whereas really it
> >  should be left alone.  I have been looking at the loop invariant
> >  code trying to figure out what needs to be changed, but so far I
> >  have not been able to puzzle it out.
> 
> Well, it's certainly not the case that register 45 is loop-invariant,  
> because it's changed in the loop by the clobber.  Maybe the loop- 
> invariant code isn't noticing the clobber?

it is loop invariant, if the code looks like

(set reg:45 some_invariant)
(the_insn_we_consider)

Zdenek