llvm dev - Oct 2004 - [LLVMdev] Fix for non-standard variable length array

In lib/CodeGen/LiveVariables.cpp a variable length array is created. 
Since this is not standard C++, it won't compile with Visual Studio (for 
interested readers, there is a discussion of why the C99 style variable 
length array is a bad idea in C++ here: 
http://www.cuj.com/documents/s=8191/cuj0209stroustr/) I have made a 
patch that uses 'new' and 'delete' instead - if this is
unacceptable for
performance reasons, I suggest just choosing some fixed size for the 
arrays (128 for example) and asserting that the actual number of 
registers is smaller than this. Patch follows.

On a side note I can now run the fibonacci example with the x86 backend 
compiled with Visual C -- For fun I compiled the fibonacci function also 
with Visual C with max. optimizes, and the LLVM compiled version is 
slightly faster! I'm impressed! More patches will follow, sorry for 
flooding...

m.

There was a similar problem some time ago, and was resolved with 
alloca. I think it's a better solution to use the stack instead of the 
heap...
---
Paolo Invernizzi

On Oct 18, 2004, at 3:12 PM, Morten Ofstad wrote:
> In lib/CodeGen/LiveVariables.cpp a variable length array is created. 
> Since this is not standard C++, it won't compile with Visual Studio 
> (for interested readers, there is a discussion of why the C99 style 
> variable length array is a bad idea in C++ here: 
> http://www.cuj.com/documents/s=8191/cuj0209stroustr/) I have made a 
> patch that uses 'new' and 'delete' instead - if this is
unacceptable
> for performance reasons, I suggest just choosing some fixed size for 
> the arrays (128 for example) and asserting that the actual number of 
> registers is smaller than this. Patch follows.
>
> On a side note I can now run the fibonacci example with the x86 
> backend compiled with Visual C -- For fun I compiled the fibonacci 
> function also with Visual C with max. optimizes, and the LLVM compiled 
> version is slightly faster! I'm impressed! More patches will follow, 
> sorry for flooding...
>
> m.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

Paolo Invernizzi wrote:
> There was a similar problem some time ago, and was resolved with alloca. 
> I think it's a better solution to use the stack instead of the heap...
I tend to agree, but the constructors won't get called if it's an object
array -- anyway, this particular case there was no objects, just 
pointers and bools so alloca should be fine. I'll leave it to Chris 
Lattner to decide if my patch goes in or not...

To reduce the number of mails, I also include my next patch -- X86 
specific code and inline assembly for Visual C, unfortunately I had to 
use the nasty IncludeFile trick again to get the linker to work..

m.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20041018/10234652/attachment.txt>

> There was a similar problem some time ago, and was resolved with alloca. 
> I think it's a better solution to use the stack instead of the heap...
Actually, I looked into this and alloca is not standard C++ since it can 
create problems for the exception handling (although it compiles fine 
with Visual C). This is probably why there have been compilation 
problems on some platforms (see 
http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-September/001992.html) -- 
A better alternative is maybe to use the std::vector instead of a VLA.

m.