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.
Paolo Invernizzi
2004-Oct-18 13:25 UTC
[LLVMdev] Fix for non-standard variable length array
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
Morten Ofstad
2004-Oct-18 13:47 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
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.
Maybe Matching Threads
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Bug in X86CompilationCallback_SSE
- [LLVMdev] Bug in X86CompilationCallback_SSE