Re: [PATCH] Improve rotate fold-const pattern matching (PR target/82498)

[Marc Glisse <marc dot glisse at inria dot fr>]

On Fri, 13 Oct 2017, Richard Biener wrote:

> On Thu, 12 Oct 2017, Jakub Jelinek wrote:
>
> > Hi!
> >
> > Marc in the PR mentioned that it is not really good that the recommended
> > rotate pattern is recognized only during forwprop1 and later, which is after
> > einline and that inlining or early opts could have changed stuff too much so
> > that we wouldn't recogize it anymore.
>
> Hmm, but the only thing functions see is inlining early optimized bodies
> into them and then constant propagation performed, so I don't see how
> we could confuse the pattern in a way to be indetectable.  Also

For instance, in

unsigned f(unsigned x, int y) { return (x << y) | (x >> (-y & 31)); }
unsigned g(unsigned x) { return f(x << 2, 3); }

if we inline f into g before optimizing f, we might combine (x << 2) << 3 
into x << 5, which would make it harder to recognize the rotation. For 
some reason that's not happening, but similar scenarios seemed possible to 
me. But if the inliner calls early optimizations (including forwprop) on 
the callee before inlining it, then my comment is indeed nonsense.

> early inlining is performed on early optimized bodies so cost metrics
> see rotates, not the unrecognized form.

Ah, so there's a hidden forwprop pass in einline?

unsigned f(unsigned x, int y) {
  unsigned z = x << y;
  return z | (x >> (-y & 31));
}
unsigned g(unsigned x, int y) { return f(x, y); }

After einline, g has rotate but not f, that's rather confusing.

--
Marc Glisse