Re: Loop invariant code corrupting xstormy16 insn

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

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