Hi! 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. I still think we would be better off without it, fwiw (anything that can be expressed in RTL using ROTATERT can be expressed just as easily with just ROTATE; it would help if me made ROTATE defined for *all* rhs values though). > earlier the code canonicalizes ROTATERT to ROTATE with the adjusted > (constant) count, I mean if the inner op is ROTATERT, why can't it > decanonicalize the outer one back to ROTATERT and treat it like that? Many targets only support the canonical form, so this will likely regress generated code quality? > PR rtl-optimization/97386 > * combine.c (simplify_shift_const_1): Don't optimize nested ROTATEs if > they have different modes. > > * gcc.c-torture/execute/pr97386-1.c: New test. > * gcc.c-torture/execute/pr97386-2.c: New test. The patch is fine, okay for trunk, thanks! Segher
