[InstCombine] Fold IEEE `fmul`/`fdiv` by Pow2 to `add`/`sub` of exp

[goldstein.w.n]

Summary

This implements:

(fmul C, (uitofp Pow2))
    -> (bitcast_to_FP (add (bitcast_to_INT C), Log2(Pow2) << mantissa))
(fdiv C, (uitofp Pow2))
    -> (bitcast_to_FP (sub (bitcast_to_INT C), Log2(Pow2) << mantissa))

The motivation is mostly fdiv where 2^(-p) is a fairly common
expression.

The patch is intentionally conservative about the transform, only
doing so if we

1. have IEEE floats
2. C is normal
3. add/sub of max(Log2(Pow2)) stays in the min/max exponent bounds.

Alive2 can't realistically prove this, but did test float16/float32
cases (within the bounds of the above rules) exhaustively.

[nikic]

Sounds plausible, but I'll leave this to the FP experts...

llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp

573

Why does this exclude scalable vectors?

625

Should call this with DoFold = false first, otherwise it'll create dead instructions. They'll get removed, but I think this will lead to an infinite combine loop.

Please add a test where this fails to fold after some sub-part has folded.

633–639

[RKSimon]

Do we do much floatbits wrangling in the middle-end? This feels like something that should be done later, but I don't know if there are precedents.

[arsenm]

My current thought is this is a worse canonical form for floating point operations and would be better done in codegen. This is going to interfere with FMA matching, plus computeKnownFPClass is going to give up on the integer ops and cast.

This is also similar to a codegen combine I’ve been planning on doing to fold fmul by power of 2 to ldexp. That has the same FMA interference properties, but is easier to deal with. Have you considered introducing ldexp instead and breaking that in codegen if ldexp isn’t legal?

[arsenm]

In D154678#4479850, @RKSimon wrote:

Do we do much floatbits wrangling in the middle-end? This feels like something that should be done later, but I don't know if there are precedents.

I actually think we need to do the opposite and turn int-to-fp, not fp-to-int (e.g. D151939 and parents).

[goldstein.w.n]

In D154678#4480022, @arsenm wrote:

My current thought is this is a worse canonical form for floating point operations and would be better done in codegen. This is going to interfere with FMA matching, plus computeKnownFPClass is going to give up on the integer ops and cast.

Is there a reason we can't handle bitcasts in computeKnownFPClass using knownbits from the integer type coming in?

I would agree with you if we were replacing the int-to-fp with a fp-to-int, but there is no float except for the constant until the fdiv/fmul.
is fmul/fdiv by constant really preferable to add/sub of a constant?

This is also similar to a codegen combine I’ve been planning on doing to fold fmul by power of 2 to ldexp. That has the same FMA interference properties, but is easier to deal with. Have you considered introducing ldexp instead and breaking that in codegen if ldexp isn’t legal?

That does seem more principled. Then we get to remove all the casts.

is (fmul/fdiv C, (uitofp Pow2)) directly equiv to (ldexp C, -/+ Log2(Pow2))? (negative log2(pow2) if fdiv)

[arsenm]

In D154678#4480988, @goldstein.w.n wrote:

In D154678#4480022, @arsenm wrote:

My current thought is this is a worse canonical form for floating point operations and would be better done in codegen. This is going to interfere with FMA matching, plus computeKnownFPClass is going to give up on the integer ops and cast.

Is there a reason we can't handle bitcasts in computeKnownFPClass using knownbits from the integer type coming in?

The cases that are recognizable would be better served by turning the bitcasts into floating point operations. Adding in some integer add and sub is quite obscuring and would make that more difficult

I would agree with you if we were replacing the int-to-fp with a fp-to-int, but there is no float except for the constant until the fdiv/fmul.
is fmul/fdiv by constant really preferable to add/sub of a constant?

Downstream users of the fmul / fdiv can understand the original float operation but the new integer thing is hopeless. If the original fmul had an fadd user, we could no longer match FMA without a lot more effort. We do have to undo some canonicalizations already for FMA formation,
but they're simple cases (like fmul x, 2 -> fadd x, x)

This is also similar to a codegen combine I’ve been planning on doing to fold fmul by power of 2 to ldexp. That has the same FMA interference properties, but is easier to deal with. Have you considered introducing ldexp instead and breaking that in codegen if ldexp isn’t legal?

That does seem more principled. Then we get to remove all the casts.

is (fmul/fdiv C, (uitofp Pow2)) directly equiv to (ldexp C, -/+ Log2(Pow2))? (negative log2(pow2) if fdiv)

Yes. I'm pretty sure all the edge cases all work out the same

[goldstein.w.n]

In D154678#4481083, @arsenm wrote:

In D154678#4480988, @goldstein.w.n wrote:

In D154678#4480022, @arsenm wrote:

My current thought is this is a worse canonical form for floating point operations and would be better done in codegen. This is going to interfere with FMA matching, plus computeKnownFPClass is going to give up on the integer ops and cast.

Is there a reason we can't handle bitcasts in computeKnownFPClass using knownbits from the integer type coming in?

The cases that are recognizable would be better served by turning the bitcasts into floating point operations. Adding in some integer add and sub is quite obscuring and would make that more difficult

I would agree with you if we were replacing the int-to-fp with a fp-to-int, but there is no float except for the constant until the fdiv/fmul.
is fmul/fdiv by constant really preferable to add/sub of a constant?

Downstream users of the fmul / fdiv can understand the original float operation but the new integer thing is hopeless. If the original fmul had an fadd user, we could no longer match FMA without a lot more effort. We do have to undo some canonicalizations already for FMA formation,
but they're simple cases (like fmul x, 2 -> fadd x, x)

This is also similar to a codegen combine I’ve been planning on doing to fold fmul by power of 2 to ldexp. That has the same FMA interference properties, but is easier to deal with. Have you considered introducing ldexp instead and breaking that in codegen if ldexp isn’t legal?

That does seem more principled. Then we get to remove all the casts.

is (fmul/fdiv C, (uitofp Pow2)) directly equiv to (ldexp C, -/+ Log2(Pow2))? (negative log2(pow2) if fdiv)

Yes. I'm pretty sure all the edge cases all work out the same

Okay, am going to abandon this patch and replace with transform to ldexp.

Will add ldexp -> shift/sub in backend.

[goldstein.w.n]

In D154678#4481138, @goldstein.w.n wrote:

In D154678#4481083, @arsenm wrote:

In D154678#4480988, @goldstein.w.n wrote:

In D154678#4480022, @arsenm wrote:

My current thought is this is a worse canonical form for floating point operations and would be better done in codegen. This is going to interfere with FMA matching, plus computeKnownFPClass is going to give up on the integer ops and cast.

Is there a reason we can't handle bitcasts in computeKnownFPClass using knownbits from the integer type coming in?

The cases that are recognizable would be better served by turning the bitcasts into floating point operations. Adding in some integer add and sub is quite obscuring and would make that more difficult

I would agree with you if we were replacing the int-to-fp with a fp-to-int, but there is no float except for the constant until the fdiv/fmul.
is fmul/fdiv by constant really preferable to add/sub of a constant?

Downstream users of the fmul / fdiv can understand the original float operation but the new integer thing is hopeless. If the original fmul had an fadd user, we could no longer match FMA without a lot more effort. We do have to undo some canonicalizations already for FMA formation,
but they're simple cases (like fmul x, 2 -> fadd x, x)

This is also similar to a codegen combine I’ve been planning on doing to fold fmul by power of 2 to ldexp. That has the same FMA interference properties, but is easier to deal with. Have you considered introducing ldexp instead and breaking that in codegen if ldexp isn’t legal?

That does seem more principled. Then we get to remove all the casts.

is (fmul/fdiv C, (uitofp Pow2)) directly equiv to (ldexp C, -/+ Log2(Pow2))? (negative log2(pow2) if fdiv)

Yes. I'm pretty sure all the edge cases all work out the same

Okay, am going to abandon this patch and replace with transform to ldexp.

Will add ldexp -> shift/sub in backend.

Working on adding ldexp to backend, but notice that we lose the important information that exp <= Type->getScalarSizeInBits().
We can't propagate an assume to the backend either.
Think to do this, need to add a flag to ldexp if exp is log of some sort (allows us to reason about whether it may cause denorm/etc).
What do you think?

Edit:
We lose also information about whether this is for fdiv or fmul which makes the bounds more constrained, although this is probably less important.

llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp

573

Just to keep it simple. Was mostly concerns we might have an issue deducing the proper integer type for bitcasting the FP constant if we allowed scalable vecs.

[goldstein.w.n]

What do you think?

You being @arsenm

[arsenm]

In D154678#4481361, @goldstein.w.n wrote:

Working on adding ldexp to backend, but notice that we lose the important information that exp <= Type->getScalarSizeInBits()

The useful exponent range is limited by ldexp. The only useful values are between -exp_min - mantissa size to exp_max, outside of that it saturates to 0/inf.

We can't propagate an assume to the backend either.
Think to do this, need to add a flag to ldexp if exp is log of some sort (allows us to reason about whether it may cause denorm/etc).

The exp is interpreted as the log value.

What do you think?

Edit:
We lose also information about whether this is for fdiv or fmul which makes the bounds more constrained, although this is probably less important.

Does that matter? Can we unconditionally turn fdiv into fmul if the divisor is known to be an exact power of 2?

I do think fmul with power of 2 constant in the general case should be more canonical than ldexp. We should turn ldexp with constant exponent into fmuls, and back into ldexp if the target wants.

[goldstein.w.n]

In D154678#4481669, @arsenm wrote:

In D154678#4481361, @goldstein.w.n wrote:

Working on adding ldexp to backend, but notice that we lose the important information that exp <= Type->getScalarSizeInBits()

The useful exponent range is limited by ldexp. The only useful values are between -exp_min - mantissa size to exp_max, outside of that it saturates to 0/inf.

We can't propagate an assume to the backend either.
Think to do this, need to add a flag to ldexp if exp is log of some sort (allows us to reason about whether it may cause denorm/etc).

The exp is interpreted as the log value.

Yeah, but that log value can be anything. We where only able to bound
it before because we actually took the log of a value that maxed at Type->getScalarSizeInBits().
In the backend, it can be anything no?
I.e if we have:

%pow = shl i64 1, %cnt
%pow_fp = uitofp i64 to double %pow
%mul = fmul double %d, %pow_fp

We convert to:

%mul = ldexp(%d, %cnt)

But when we see this in the backend we have no way to bounding cnt.

What do you think?

Edit:
We lose also information about whether this is for fdiv or fmul which makes the bounds more constrained, although this is probably less important.

Does that matter? Can we unconditionally turn fdiv into fmul if the divisor is known to be an exact power of 2?

I do think fmul with power of 2 constant in the general case should be more canonical than ldexp. We should turn ldexp with constant exponent into fmuls, and back into ldexp if the target wants.

The thing is the power of not constant.
The fold is:
(fmul FP_Constant, (uitofp Pow2_Int_Variable))

[goldstein.w.n]

Can we unconditionally turn fdiv into fmul if the divisor is known to be an exact power of 2?

Not sure, best I can come up with just take reciprical.

[goldstein.w.n]

Would people be more open to the patch in InstCombine if it was only for fdiv? The concerns about making things less canonical have been mostly centered around fmul.

[goldstein.w.n]

D154805 has the backend impl, going to keep this open for a moment incase people prefer just removing fmul from this patch.

[arsenm]

In D154678#4481841, @goldstein.w.n wrote:

Can we unconditionally turn fdiv into fmul if the divisor is known to be an exact power of 2?

Not sure, best I can come up with just take reciprical.

Seems to work for power of 2 known <= max_exp. Much better to do that rather than try to handle both

[goldstein.w.n]

In D154678#4486086, @arsenm wrote:

In D154678#4481841, @goldstein.w.n wrote:

Can we unconditionally turn fdiv into fmul if the divisor is known to be an exact power of 2?

Not sure, best I can come up with just take reciprical.

Seems to work for power of 2 known <= max_exp. Much better to do that rather than try to handle both

So you mean handle fdiv only and do the following:

(fdiv C, (uitofp Pow2))
    -> (fmul C, (bitcast_to_FP (sub (FP_One), Log2(Pow2) << mantissa)))

?
Otherwise we still have the division to create the RCP. In this case
Seems we might as well also drop the fmul.

But I'm planning to abandon this patch as have implemented in the backend.

[arsenm]

In D154678#4486199, @goldstein.w.n wrote:

So you mean handle fdiv only and do the following:

(fdiv C, (uitofp Pow2))
    -> (fmul C, (bitcast_to_FP (sub (FP_One), Log2(Pow2) << mantissa)))

Yes. It seems InstCombine already turns fdiv by constant power of 2 to fmul, but not the unknown-but-known-to-be-pow2 case here

[goldstein.w.n]

In D154678#4486204, @arsenm wrote:

In D154678#4486199, @goldstein.w.n wrote:

So you mean handle fdiv only and do the following:

(fdiv C, (uitofp Pow2))
    -> (fmul C, (bitcast_to_FP (sub (FP_One), Log2(Pow2) << mantissa)))

Yes. It seems InstCombine already turns fdiv by constant power of 2 to fmul, but not the unknown-but-known-to-be-pow2 case here

In the constant case, RCP(Constant) is free, here we need 3-4 instructions. Is that really more canonical?
Would argument we might as well drop the fmul entirely and stick with the original transform (for fdiv only)
or just drop entirely and rely on the backend patch.

[goldstein.w.n]

ping. Would very much so like to get this in. Even if we end up re-routing through ldexp in the future, think the base of this will remain the same.

[goldstein.w.n]

@arsenm I added some AMDGPU tests + some tests of ldexp so its easier to compare the results of this patch.
I would also be happy to add patch so this code can also generate ldexp for the fmul case if the target prefers it if that helps address your concerns.

Edit: Realize this is wrong commit ive been pinging on.

[goldstein.w.n]

wrong commit.... ive been messaging on :(

llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp

if (match(Op0, m_FAbs(m_Value(X))) && match(Op1, m_FAbs(m_Value(Y))) &&
     Value *Fabs = Builder.CreateUnaryIntrinsic(Intrinsic::fabs, XY);
     Fabs->takeName(&I);
     return replaceInstUsesWith(I, Fabs);
   }
 
   return nullptr;
 }
 
+// Transform IEEE Floats:
+//      (fmul C, (uitofp Pow2))
+//          -> (bitcast_to_FP (add (bitcast_to_INT C), Log2(Pow2) << mantissa))
+//      (fdiv C, (uitofp Pow2))
+//          -> (bitcast_to_FP (sub (bitcast_to_INT C), Log2(Pow2) << mantissa))
+//
+//      The rationale is fmul/fdiv by a power of 2 is just change the
+//      exponent, so there is no need for more than an add/sub.
+//
+//      This is valid under the following circumstances:
+//      1) We are dealing with IEEE floats
+//      2) C is normal
+//      3) The fmul/fdiv add/sub will not go outside of min/max exponent bounds.
+static Instruction *foldFMulOrFDivOfConstantAndIntPow2(InstCombinerImpl &IC,
+                                                       const SimplifyQuery &Q,
+                                                       BinaryOperator &I) {
+  Type *FPTy = I.getType();
+  // Only do IEEE floats. Also skip scalable vecs.
+  if (!FPTy->getScalarType()->isIEEELikeFPTy() || FPTy->isScalableTy())
+    return nullptr;
+
+  // Make sure we can get a valid mantissa.
+  int Mantissa = FPTy->getFPMantissaWidth() - 1;
+  if (Mantissa <= 0)
+    return nullptr;
+
+  // We are explicitly only matching FDiv where the denominator is a Pow2
+  // Integer. This means the constant must be the first operand. For FMul,
+  // however, the constant will canonicalize to the second argument.
+  unsigned ConstOpIdx = I.getOpcode() == Instruction::FMul;
+  unsigned UIToFPOpIdx = 1 - ConstOpIdx;
+
+  const APFloat *APF;
+  if (!match(I.getOperand(ConstOpIdx), m_APFloat(APF)))
+    return nullptr;
+
+  // Make sure we have normal float (there might be some cases where this works
+  // for subnormal, but thats probably rare and code in not worth the risk of a
+  // bug).
+  if (!APF->isNormal() || !APF->isIEEE())
+    return nullptr;
+
+  Value *V;
+  if (!match(I.getOperand(UIToFPOpIdx), m_UIToFP(m_Value(V)))) {
+    // We can match (sitofp Pow2) if we know Pow2 is non-negative. Doing this in
+    // InstCombineCasts causes regressions.
+    // TODO: Remove this if InstCombineCasts is ever updated.
+    if (!match(I.getOperand(UIToFPOpIdx), m_SIToFP(m_Value(V))) ||
+        !isKnownNonNegative(V, Q.DL, 0, Q.AC, Q.CxtI, Q.DT))
+      return nullptr;
+  }
+
+  // Make sure add/sub will never breach the bounds of min/max exponent. We
+  // could be a little more clever here if we used knownbits to get an
+  // upperbound of V, but most floats are well within the bounds so its probably
+  // not worth the risk of a bug to handle such a rare case.
+  int MaxExpChange = V->getType()->getScalarSizeInBits();
+  int CurExp = ilogb(*APF);
+  int NewExpBound = I.getOpcode() == Instruction::FMul
+                        ? (CurExp + MaxExpChange)
+                        : (CurExp - MaxExpChange);
+  if (NewExpBound <= APFloat::semanticsMinExponent(APF->getSemantics()) ||
+      NewExpBound >= APFloat::semanticsMaxExponent(APF->getSemantics()))
+    return nullptr;
+
+  // Finally check if the integer is a Pow2 we can get the log of. All other
+  // checks need to be before this, as takeLog2 will create our log instruction.
+  Value *Log2 =
+      takeLog2(IC.Builder, V, /*Depth*/ 0, /*AssumeNonZero*/
+               isKnownNonZero(V, Q.DL, /*Depth*/ 0, Q.AC, Q.CxtI, Q.DT),
+               /*DoFold*/ true);
+  if (Log2 == nullptr)
+    return nullptr;
+
+  // uintofp can change bitwidth, so need to cast our Log2 value to proper
+  // integer width.
+  unsigned FPWidth = FPTy->getScalarSizeInBits();
+  Type *IntTy = Type::getIntNTy(I.getContext(), FPWidth);
+  if (FPTy->isVectorTy()) {
+    auto *FVTy = dyn_cast<FixedVectorType>(FPTy);
+    assert(FVTy &&
+           "We should have already made sure this is not a scalable type!");
+    IntTy =
+        VectorType::get(IntTy, ElementCount::getFixed(FVTy->getNumElements()));
+  }
+  Value *CastedLog2 = IC.Builder.CreateZExtOrTrunc(Log2, IntTy);
+
+  // Do actual fold.
+  Value *ShiftedLog2 = IC.Builder.CreateBinOp(
+      Instruction::Shl, CastedLog2, ConstantInt::get(IntTy, Mantissa));
+  Value *BitwiseMulOrDiv = IC.Builder.CreateBinOp(
+      I.getOpcode() == Instruction::FMul ? Instruction::Add : Instruction::Sub,
+      IC.Builder.CreateBitCast(I.getOperand(ConstOpIdx), IntTy), ShiftedLog2);
+  Value *R = IC.Builder.CreateBitCast(BitwiseMulOrDiv, FPTy);
+  return IC.replaceInstUsesWith(I, R);
+}
+
 Instruction *InstCombinerImpl::visitFMul(BinaryOperator &I) {
   if (Value *V = simplifyFMulInst(I.getOperand(0), I.getOperand(1),
                                   I.getFastMathFlags(),
                                   SQ.getWithInstruction(&I)))
     return replaceInstUsesWith(I, V);
 
   if (SimplifyAssociativeOrCommutative(I))
     return &I;
if (match(&I,
     // We cannot preserve ninf if nnan flag is not set.
     // If X is NaN and Y is Inf then in original program we had NaN * NaN,
     // while in optimized version NaN * Inf and this is a poison with ninf flag.
     if (!Result->hasNoNaNs())
       Result->setHasNoInfs(false);
     return Result;
   }
 
+  const SimplifyQuery Q = SQ.getWithInstruction(&I);
+  if (Instruction *R = foldFMulOrFDivOfConstantAndIntPow2(*this, Q, I))
+    return R;
+
   return nullptr;
 }
 
 /// Fold a divide or remainder with a select instruction divisor when one of the
 /// select operands is zero. In that case, we can use the other select operand
 /// because div/rem by zero is undefined.
 bool InstCombinerImpl::simplifyDivRemOfSelectWithZeroOp(BinaryOperator &I) {
   SelectInst *SI = dyn_cast<SelectInst>(I.getOperand(1));
if (I.hasAllowReassoc() &&
       match(Op0, m_OneUse(m_Intrinsic<Intrinsic::pow>(m_Specific(Op1),
                                                       m_Value(Y))))) {
     Value *Y1 =
         Builder.CreateFAddFMF(Y, ConstantFP::get(I.getType(), -1.0), &I);
     Value *Pow = Builder.CreateBinaryIntrinsic(Intrinsic::pow, Op1, Y1, &I);
     return replaceInstUsesWith(I, Pow);
   }
 
+  const SimplifyQuery Q = SQ.getWithInstruction(&I);
+  if (Instruction *R = foldFMulOrFDivOfConstantAndIntPow2(*this, Q, I))
+    return R;
+
   return nullptr;
 }
 
 // Variety of transform for:
 //  (urem/srem (mul X, Y), (mul X, Z))
 //  (urem/srem (shl X, Y), (shl X, Z))
 //  (urem/srem (shl Y, X), (shl Z, X))
 // NB: The shift cases are really just extensions of the mul case. We treat

llvm/test/Transforms/InstCombine/fmul-and-fdiv-by-int-pow2.ll

 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 3
 ; RUN: opt < %s -passes=instcombine -S | FileCheck %s
 
 define double @fmul_dbl_pow_1_shl_cnt(i64 %cnt) {
 ; CHECK-LABEL: define double @fmul_dbl_pow_1_shl_cnt
 ; CHECK-SAME: (i64 [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw i64 1, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp i64 [[SHL]] to double
-; CHECK-NEXT:    [[MUL:%.*]] = fmul double [[CONV]], 9.000000e+00
+; CHECK-NEXT:    [[TMP1:%.*]] = shl i64 [[CNT]], 52
+; CHECK-NEXT:    [[TMP2:%.*]] = add i64 [[TMP1]], 4621256167635550208
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast i64 [[TMP2]] to double
 ; CHECK-NEXT:    ret double [[MUL]]
 ;
   %shl = shl nuw i64 1, %cnt
   %conv = uitofp i64 %shl to double
   %mul = fmul double 9.000000e+00, %conv
   ret double %mul
 }
 
;
   %conv = uitofp i64 %shl to double
   %mul = fmul double 9.000000e+00, %conv
   ret double %mul
 }
 
 define float @fmul_pow_1_shl_cnt(i64 %cnt) {
 ; CHECK-LABEL: define float @fmul_pow_1_shl_cnt
 ; CHECK-SAME: (i64 [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw nsw i64 8, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp i64 [[SHL]] to float
-; CHECK-NEXT:    [[MUL:%.*]] = fmul float [[CONV]], -9.000000e+00
+; CHECK-NEXT:    [[TMP1:%.*]] = trunc i64 [[CNT]] to i32
+; CHECK-NEXT:    [[TMP2:%.*]] = shl i32 [[TMP1]], 23
+; CHECK-NEXT:    [[TMP3:%.*]] = add i32 [[TMP2]], -1030750208
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast i32 [[TMP3]] to float
 ; CHECK-NEXT:    ret float [[MUL]]
 ;
   %shl = shl nsw nuw i64 8, %cnt
   %conv = uitofp i64 %shl to float
   %mul = fmul float -9.000000e+00, %conv
   ret float %mul
 }
 
 define <2 x float> @fmul_pow_2_shl_cnt_vec(<2 x i64> %cnt) {
 ; CHECK-LABEL: define <2 x float> @fmul_pow_2_shl_cnt_vec
 ; CHECK-SAME: (<2 x i64> [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw nsw <2 x i64> <i64 2, i64 2>, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp <2 x i64> [[SHL]] to <2 x float>
-; CHECK-NEXT:    [[MUL:%.*]] = fmul <2 x float> [[CONV]], <float 1.500000e+01, float 1.500000e+01>
+; CHECK-NEXT:    [[TMP1:%.*]] = trunc <2 x i64> [[CNT]] to <2 x i32>
+; CHECK-NEXT:    [[TMP2:%.*]] = shl <2 x i32> [[TMP1]], <i32 23, i32 23>
+; CHECK-NEXT:    [[TMP3:%.*]] = add <2 x i32> [[TMP2]], <i32 1106247680, i32 1106247680>
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast <2 x i32> [[TMP3]] to <2 x float>
 ; CHECK-NEXT:    ret <2 x float> [[MUL]]
 ;
   %shl = shl nsw nuw <2 x i64> <i64 2, i64 2>, %cnt
   %conv = uitofp <2 x i64> %shl to <2 x float>
   %mul = fmul <2 x float> <float 15.000000e+00, float 15.000000e+00>, %conv
   ret <2 x float> %mul
 }
 
;
   %conv = uitofp i64 %shl to double
   %mul = fmul double 9.745314e+288, %conv
   ret double %mul
 }
 
 define double @fmul_pow_1_shl_cnt_safe(i16 %cnt) {
 ; CHECK-LABEL: define double @fmul_pow_1_shl_cnt_safe
 ; CHECK-SAME: (i16 [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw i16 1, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp i16 [[SHL]] to double
-; CHECK-NEXT:    [[MUL:%.*]] = fmul double [[CONV]], 0x7BEFFFFFFF5F3992
+; CHECK-NEXT:    [[TMP1:%.*]] = zext i16 [[CNT]] to i64
+; CHECK-NEXT:    [[TMP2:%.*]] = shl i64 [[TMP1]], 52
+; CHECK-NEXT:    [[TMP3:%.*]] = add i64 [[TMP2]], 8930638061065157010
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast i64 [[TMP3]] to double
 ; CHECK-NEXT:    ret double [[MUL]]
 ;
   %shl = shl nuw i16 1, %cnt
   %conv = uitofp i16 %shl to double
   %mul = fmul double 9.745314e+288, %conv
   ret double %mul
 }
 
 define <2 x double> @fdiv_pow_1_shl_cnt_vec(<2 x i64> %cnt) {
 ; CHECK-LABEL: define <2 x double> @fdiv_pow_1_shl_cnt_vec
 ; CHECK-SAME: (<2 x i64> [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw <2 x i64> <i64 1, i64 1>, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp <2 x i64> [[SHL]] to <2 x double>
-; CHECK-NEXT:    [[MUL:%.*]] = fdiv <2 x double> <double 1.000000e+00, double 1.000000e+00>, [[CONV]]
+; CHECK-NEXT:    [[TMP1:%.*]] = shl <2 x i64> [[CNT]], <i64 52, i64 52>
+; CHECK-NEXT:    [[TMP2:%.*]] = sub <2 x i64> <i64 4607182418800017408, i64 4607182418800017408>, [[TMP1]]
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast <2 x i64> [[TMP2]] to <2 x double>
 ; CHECK-NEXT:    ret <2 x double> [[MUL]]
 ;
   %shl = shl nuw <2 x i64> <i64 1, i64 1>, %cnt
   %conv = uitofp <2 x i64> %shl to <2 x double>
   %mul = fdiv <2 x double> <double 1.000000e+00, double 1.000000e+00>, %conv
   ret <2 x double> %mul
 }
 
;
   %conv = sitofp i64 %shl to float
   %mul = fdiv float -9.000000e+00, %conv
   ret float %mul
 }
 
 define float @fdiv_pow_1_shl_cnt(i64 %cnt_in) {
 ; CHECK-LABEL: define float @fdiv_pow_1_shl_cnt
 ; CHECK-SAME: (i64 [[CNT_IN:%.*]]) {
-; CHECK-NEXT:    [[CNT:%.*]] = and i64 [[CNT_IN]], 31
-; CHECK-NEXT:    [[SHL:%.*]] = shl i64 8, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = sitofp i64 [[SHL]] to float
-; CHECK-NEXT:    [[MUL:%.*]] = fdiv float -5.000000e-01, [[CONV]]
+; CHECK-NEXT:    [[TMP1:%.*]] = trunc i64 [[CNT_IN]] to i32
+; CHECK-NEXT:    [[TMP2:%.*]] = shl i32 [[TMP1]], 23
+; CHECK-NEXT:    [[TMP3:%.*]] = and i32 [[TMP2]], 260046848
+; CHECK-NEXT:    [[TMP4:%.*]] = sub nuw nsw i32 -1115684864, [[TMP3]]
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast i32 [[TMP4]] to float
 ; CHECK-NEXT:    ret float [[MUL]]
 ;
   %cnt = and i64 %cnt_in, 31
   %shl = shl i64 8, %cnt
   %conv = sitofp i64 %shl to float
   %mul = fdiv float -0.500000e+00, %conv
   ret float %mul
 }
;
   %conv = uitofp i32 %shl to half
   %mul = fdiv half 0xH7000, %conv
   ret half %mul
 }
 
 define half @fdiv_pow_1_shl_cnt_in_bounds(i16 %cnt) {
 ; CHECK-LABEL: define half @fdiv_pow_1_shl_cnt_in_bounds
 ; CHECK-SAME: (i16 [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw i16 1, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp i16 [[SHL]] to half
-; CHECK-NEXT:    [[MUL:%.*]] = fdiv half 0xH7000, [[CONV]]
+; CHECK-NEXT:    [[TMP1:%.*]] = shl i16 [[CNT]], 10
+; CHECK-NEXT:    [[TMP2:%.*]] = sub i16 28672, [[TMP1]]
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast i16 [[TMP2]] to half
 ; CHECK-NEXT:    ret half [[MUL]]
 ;
   %shl = shl nuw i16 1, %cnt
   %conv = uitofp i16 %shl to half
   %mul = fdiv half 0xH7000, %conv
   ret half %mul
 }
 
 define half @fdiv_pow_1_shl_cnt_in_bounds2(i16 %cnt) {
 ; CHECK-LABEL: define half @fdiv_pow_1_shl_cnt_in_bounds2
 ; CHECK-SAME: (i16 [[CNT:%.*]]) {
-; CHECK-NEXT:    [[SHL:%.*]] = shl nuw i16 1, [[CNT]]
-; CHECK-NEXT:    [[CONV:%.*]] = uitofp i16 [[SHL]] to half
-; CHECK-NEXT:    [[MUL:%.*]] = fdiv half 0xH4800, [[CONV]]
+; CHECK-NEXT:    [[TMP1:%.*]] = shl i16 [[CNT]], 10
+; CHECK-NEXT:    [[TMP2:%.*]] = sub i16 18432, [[TMP1]]
+; CHECK-NEXT:    [[MUL:%.*]] = bitcast i16 [[TMP2]] to half
 ; CHECK-NEXT:    ret half [[MUL]]
 ;
   %shl = shl nuw i16 1, %cnt
   %conv = uitofp i16 %shl to half
   %mul = fdiv half 0xH4800, %conv
   ret half %mul
 }