[llvm-commits] [llvm] r133285 - /llvm/trunk/lib/Transforms/InstCombine/InstCombineCasts.cpp

[John McCall]

On Jun 19, 2011, at 5:58 AM, Duncan Sands wrote:
>> +  // Insist that the amount-to-allocate not overflow.
>> +  OverflowingBinaryOperator *OBI = dyn_cast<OverflowingBinaryOperator>(Val);
>> +  if (OBI&&  !OBI->hasNoUnsignedWrap()) return 0;
> 
> I noticed you dropped the test for NSW.  I thought this was a problem because
> front-ends generally don't ever produce NUW, though they may produce NSW...

Stuart asked me to look at this, and I gave him a quick answer
that it's generally correct for nuw arithmetic, but that I wasn't as
certain for nsw arithmetic.  Now I think it's probably fine for either
as long as it's homogenous throughout.

The main restriction on the alloca size argument can be expressed as:
  (N * sizeof(T)) udiv sizeof(T) == N
However, there's a second restriction, which is that it's undefined
behavior to allocate something too large for the stack.  Technically
this is target-specific, but if we just assume by fiat that 2^31 is too large,
then as long as the arithmetic is being done in some reasonable size
then we know that N * sizeof(T) isn't permitted to signed overflow, either.

In general, if we have a nsw or nuw polynomial, I believe it is legal to
factor a nsw or nuw (respectively) multiply by a positive constant out
of it.  That's definitely not true of a zero constant, and it's not true of all
negative constants — notably, (k) * -1 + ((2 << 31) - k) * -1 does not
signed-overflow — but I believe it's true of all positive constants,
which sizeof(T) will be.

John.