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

[Zhou Sheng]

在 2007-03-29四的 23:20 -0700，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).
This patch was committed two days ago. I'll update it to use the new
ConstantInt method.


Sheng.


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