在 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@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
