On Tue, Oct 13, 2020 at 07:03:15PM +0200, Jakub Jelinek wrote: > On Tue, Oct 13, 2020 at 11:47:10AM -0500, Segher Boessenkool wrote: > > On Tue, Oct 13, 2020 at 09:44:25AM +0200, Jakub Jelinek wrote: > > > The following testcases are miscompiled (the first one since my > > > improvements > > > to rotate discovery on GIMPLE, the other one for many years) because > > > combiner optimizes nested ROTATEs with narrowing SUBREG in between (i.e. > > > the outer rotate is performed in shorter precision than the inner one) to > > > just one ROTATE of the rotated constant. While that (under certain > > > conditions) can work for shifts, it can't work for rotates where we can > > > only > > > do that with rotates of the same precision. > > > > > OT, on the other side I wonder why the code doesn't handle ROTATERT. > > > While > > > > ROTATERT is a relatively recent invention, and isn't handled in many > > places. > > Depends on how we define recent. > I see ROTATERT already in 1994 code ;)
Wow, it is even in the 1991 original revision already. I just never saw it used, I guess :-) What is new is that we canonicalize to ROTATERT from ROTATE, if that makes the constant rotate amount smaller (and both forms are allowed at all) (which contradicts the documentation btw: the docs say that rotatert by a constant is not canonical!) Segher
