[llvm-commits] CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp

[Reid Spencer]

On Thu, 2007-03-29 at 23:08 -0700, Chris Lattner wrote:
> On Mar 28, 2007, at 6:57 PM, Zhou Sheng wrote:
> 
> > @@ -540,8 +540,10 @@
> >        if (I->getOpcode() == Instruction::Shl)
> >          if ((CST = dyn_cast<ConstantInt>(I->getOperand(1)))) {
> >            // The multiplier is really 1 << CST.
> > -          Constant *One = ConstantInt::get(V->getType(), 1);
> > -          CST = cast<ConstantInt>(ConstantExpr::getShl(One, CST));
> > +          uint32_t BitWidth = cast<IntegerType>(V->getType())- 
> > >getBitWidth();
> > +          uint32_t CSTVal = CST->getValue().getActiveBits() > 64 ?
> > +                              BitWidth : CST->getZExtValue();
> > +          CST = ConstantInt::get(APInt(BitWidth, 1).shl(CSTVal));
> >            return I->getOperand(0);
> >          }
> >      }
> 
> I don't understand the logic here for the >64 active bits case.  Is  
> the idea that the operation is undefined anyway?

Yes. The CST constant is the operand 1 of a shift, the shift amount. As
you noted in previous commits, we have to guard against using
getZExtValue even on shift amounts because they could be huge (> 64
bits). In such situations, we just set the shift amount to the bit width
(also undefined) and avoid the getZExtValue (and avoid the assert).

There will be several more of these. Actually I asked Sheng to change
these to use a new method on ConstantInt since the idiom appears to be
cropping up all over the place (every shift examination).

Reid.

> 
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits