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

[John McCall]

On Jun 21, 2011, at 4:57 AM, Duncan Sands wrote:
> I thought *you* were suggesting that we assume no overflow when you said "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."  I guess I misunderstood.  I'm still not
> sure what you were trying to say :)

I was suggesting that we could make more aggressive restrictions on the
size input to alloca based on a basic assumption that you can't grow your stack
to >2GB, even on >32-bit architectures.  But if we want to support that, then
obviously this needs to be based on the pointer width.

> That's the whole point of this discussion.
>> There's an implicit multiply in sizeof(sp) as part of the alloca instruction, and
>> it's undefined behavior if either
>>  - that multiply causes unsigned overflow or
> 
> Sure.
> 
>>  - either the input or output to that multiply is negative.
> 
> Why?  Are you saying that an alloca of 2^31 i8's should be considered to result
> in undefined behaviour?

On a 32-bit machine, yes.  Are you really saying that we need to
support any argument to alloca that's smaller than the addressable
space of the machine?

If so, this transformation is completely dead;  feel free to remove it.

> And what about this: alloca i8, i8 128

I did say "in sizeof(sp)" above.

John.