[LLVMdev] Clarification between <type> and <ty> for alloca instruction

[Daniel Liew]

Thanks for the reply.

Please see my inline responses.
On 15/08/13 12:58, Tim Northover wrote:
> Hi Dan,
> 
>> It is not stated how the "<ty>" type is used as we are told the
>> type of result is type* and sizeof(<type>)*NumElements is the
>> amount of memory so from my perspective it looks like <ty> is
>> never used which would seem to make stating i32 twice in the
>> following example redundant
>> 
>> %ptr = alloca i32, i32 4
>> 
>> My guess is that if <NumElements> is specified then the amount of
>> memory actually allocated would be sizeof(<ty>)*NumElements
>> (instead of sizeof(<type>)*NumElements) but the pointer type of
>> result is <type>. Is that correct?

Ah so my guess is completely wrong. <ty> refers to the type of
NumElements.

> It doesn't really affect the output at all. If NumElements doesn't 
> overflow <ty> then the semantics don't depend on it at all.
> 
> In C-like code it's sort of the difference between these two
> functions:
> 
> void ty_is_i16(unsigned short NumElements) { int arr[NumElements]; 
> use_array(arr); }
> 
> void ty_is_i32(unsigned int NumElements) { int arr[NumElements]; 
> use_array(arr); }
> 
> you might compile them to
> 
> define void @ty_is_i16(i16 %NumElements) { %arr = alloca i32, i16
> %NumElements call void @use_array(i32* %arr) ret void }
> 
> define void @ty_is_i32(i32 %NumElements) { %arr = alloca i32, i32
> %NumElements call void @use_array(i32* %arr) ret void }

Huh... I've obviously being playing with C++ too long because my
instinct immediately told me that dynamically sized arrays on the
stack are't allowed but apparently that's fine for C99 (g++ also seems
fine with this is you don't specify -pedantic)

> Of course, if NumElements *does* overflow they're different: alloca
> i32, i8 257 will allocate 1 i32, but alloca i32, i32 257 will
> allocate 257 of them.

Interesting thanks for clarifying. Now you've raised another question.
I'm interested to know how you know that this is how overflow behaves
for this particular instruction. I can imagine several different
behaviours (I'm assuming NumElements is unsigned but that doesn't seem
to be specified)

- wrap around overflow. In which case 257 = 255 + 2 so result would be 2
- Saturation overflow. In which case the result is 255
- Your stated result of 1. I'm not sure why this would happen.


Thanks,
Dan.