[PATCH] Patch for PR19753 InstCombine: constant comparison involving "ashr exact" not optimized well

[Rafael Espíndola]

> +    // PR19753:
> +    // (icmp (ashr exact const1, A), const2) -> icmp A, Log2(const1/const2)
> +    {
> +      ConstantInt *CI2;
> +      Value *V;
> +      if (match(Op0, m_AShr(m_ConstantInt(CI2), m_Value(V))) &&
> +          (cast<BinaryOperator>(Op0)->isExact())) {
> +        APInt Quotient = CI2->getValue().sdiv(CI->getValue());

const1 in the comment is CI2 and const2 is CI, which is a bit confusing :-)

If const2 doesn't exactly divide const1 I think we can produce a
undef, which is probably more profitable, right?


> +        unsigned shift = Quotient.logBase2();

Some thing if the log is not exact. That means that the exact flag in
the ashr was wrong.

Could lshr be handled in a similar (udiv instead of sdiv) way if it
has an exact flag?

Not sure if you want to handle these now or in another patch, but at
least add a FIXME comment.

> +        return new ICmpInst(I.getPredicate(), V,
> +                            ConstantInt::get(V->getType(), shift));
> +      }
> +    }
> +
>      // If we have an icmp le or icmp ge instruction, turn it into the
>      // appropriate icmp lt or icmp gt instruction.  This allows us to rely on
>      // them being folded in the code below.  The SimplifyICmpInst code has
> Index: test/Transforms/InstCombine/icmp.ll
> ===================================================================
> --- test/Transforms/InstCombine/icmp.ll
> +++ test/Transforms/InstCombine/icmp.ll
> @@ -1365,3 +1365,11 @@
>    %2 = icmp slt i32 %1, -10
>    ret i1 %2
>  }
> +
> +; CHECK-LABEL: @exact_ashr_eq_false
> +; CHECK-NEXT: icmp eq i32 %a, 1
> +define i1 @exact_ashr_eq_false(i32 %a) {
> +  %shr = ashr exact i32 -30, %a
> +  %cmp = icmp eq i32 %shr, -15
> +  ret i1 %cmp
> +}