On Wed, Nov 11, 2020 at 12:28:28PM +0100, Richard Biener via Gcc-patches wrote:
> > +/* Fold (x << C), where C > precision(type) into 0. */
> > +(simplify
> > + (lshift @0 INTEGER_CST@1)
> > + (if (wi::ltu_p (TYPE_PRECISION (TREE_TYPE (@0)), wi::to_wide(@1)))
>
> You want element_precision (@0), otherwise this breaks for vector
> shifts by scalars.
>
> Please move it in the section starting with
>
> /* Simplifications of shift and rotates. */
>
> you should be able to write a testcase. When looking at
>
> int foo(int a)
> {
> return a << 33;
> }
>
> I see the shift eliminated to zero by early constant propagation, but with
> -fno-tree-ccp I see it prevails to the assembler.
If we do want to do this, wouldn't it be better done in vrp instead?
I mean, if we want to optimize x << 33 to 0, don't we want to also optimize
x << [32, 137] to 0 too, or
x >= 32 ? 1 << x : 0 to 0, etc.?
For the cswitch, the question is where the out of bounds shift comes from
and if it isn't compiler's fault that it made it into the IL.
Jakub
