On Fri, 2020-01-03 at 09:16 +0100, Jakub Jelinek wrote:
> Hi!
>
> As can be seen in the testcase, for the (x >> c) << c optimization into
> x & (-1<<c) we don't really care if the right shift is aritmetic or logical,
> as the affected bits are shifted away.
> Furthermore, while match.pd can handle
> ((unsigned long long)(unsigned)(x >> 32))<<32
> for unsigned long long x - we figure out that after the logical right shift
> the upper 32 bits are already zero and optimize away those two casts -
> we don't handle that for arithmetic shift or e.g. for
> ((unsigned long long)(int)(x >> 32))<<32
> Still, the upper 32 bits don't really matter on the result and can be
> anything.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2019-01-03 Jakub Jelinek <ja...@redhat.com>
>
> PR tree-optimization/93118
> * match.pd ((x >> c) << c -> x & (-1<<c)): Add nop_convert?. Add new
> simplifier with two intermediate conversions.
>
> * gcc.dg/tree-ssa/pr93118.c: New test.
OK
jeff
>
