Daniel Liew
2013-Aug-15 14:54 UTC
[LLVMdev] Clarification between <type> and <ty> for alloca instruction
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.
Tim Northover
2013-Aug-15 15:12 UTC
[LLVMdev] Clarification between <type> and <ty> for alloca instruction
> 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)It's all fun and games until someone decides to evaluate sizeof(arr). ;-) I think a more limited form is coming to C++11, by the way.> 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 2This is what happens (wraparound/truncation/whatever). But I think 256 -> 0, 257 -> 1. Cheers. Tim.
Karen Shaeffer
2013-Aug-15 18:40 UTC
[LLVMdev] Clarification between <type> and <ty> for alloca instruction
On Thu, Aug 15, 2013 at 04:12:13PM +0100, Tim Northover wrote:> > 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) > > It's all fun and games until someone decides to evaluate sizeof(arr). ;-) > > I think a more limited form is coming to C++11, by the way. >Hi Tim, I believe standard support for dynamically sized arrays is in the C++14 draft. But sizeof(arr) still will be a compile time computation, so it won't be supported in C++14 either. enjoy, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb
Maybe Matching Threads
- [LLVMdev] Clarification between <type> and <ty> for alloca instruction
- [LLVMdev] Clarification between <type> and <ty> for alloca instruction
- [LLVMdev] Clarification between <type> and <ty> for alloca instruction
- [LLVMdev] malloc(), free(), and alloca() with zero size
- [LLVMdev] Question concerning alloca