> > 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
