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

[Reid Spencer]

On Sun, 2007-03-25 at 00:55 -0400, Nick Lewycky wrote:
> Chris Lattner wrote:
> > On Mar 23, 2007, at 11:46 AM, Reid Spencer wrote:
> > 
> >>   // shl uint X, 32 = 0 and shr ubyte Y, 9 = 0, ... just don't  
> >>eliminate shr
> >>   // of a signed value.
> >>   //
> >>-  unsigned TypeBits = Op0->getType()->getPrimitiveSizeInBits();
> >>-  if (Op1->getZExtValue() >= TypeBits) {
> >>+  if (Op1->getZExtValue() >= TypeBits) {  // shift amount always  
> >><= 32 bits
> > 
> > 
> > This isn't safe.  Code like:
> > 
> > shl i1024 %A, 123456789123456789123456789123456789
> > 
> > is undefined but legal.  The compiler should not crash on it.
> 
> What exactly is undefined? 

The result of the shift operation is undefined (any shift >= size of
integer type is undefined).

> Just the result of that single instruction,
> or the behaviour of any program that attempts to execute it? 

The behavior of the program may go awry but just the instruction result
is undefined.

> Would it be
> acceptable to replace such an instruction with "unreachable"?

No.

> 
> If so, then it gives me a new source of information for predsimplify.
> After the instruction executes, I can assume that the RHS of a shift is
> within range.

huh? The RHS of the shift is some number. You can't say anything about
it.

It is the result of the shift that becomes undefined when the value
exceeds the bit width of the quantity being shifted.  What you could
assume is that the result of such shifts matches anything. But I'm not
sure you'd want to base an optimization on that.

Reid.

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