Hello, > > 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. > > > > I think that the real problem might be the clobbers in the > > ineqbranchsi pattern, but I do not know how it could be changed to > > fix this. > > > > Any ideas ? > > invariant motion needs to verify that reg:45 is dead at the beginning of the > loop.
actually, I probably misunderstood what you meant. The problem is that invariant motion rewrites just part of the considered insn, changing reg:45 to another register in if_then_else, but leaving it the same in the clobber? Zdenek
