LLVMX86Disassembler fails to compile properly in optimize mode by Nat

any updates or workarounds? I still see the same problem with LLVM 3.0

C:\workspace\llvm-3.0.src\build\MinSizeRel>type "C:\Documents and Settings\nluen
gn1\Local Settings\Temp\6a66a104ed85495481c6317003243a27.rsp"
/c /I"C:/workspace/llvm-3.0.src/build/lib/Target/X86/Disassembler" /I"C:/workspa
ce/llvm-3.0.src/lib/Target/X86/Disassembler" /I"C:/workspace/llvm-3.0.src/lib/Ta
rget/X86" /I"C:/workspace/llvm-3.0.src/build/lib/Target/X86" /I"C:/workspace/llv
m-3.0.src/build/include" /I"C:/workspace/llvm-3.0.src/include" /I"C:/workspace/l
lvm-3.0.src/build/lib/Target/X86/Disassembler/.." /I"C:/workspace/llvm-3.0.src/l
ib/Target/X86/Disassembler/.." /nologo /W3 /WX- /MP /O1 /Ob1 /Oy- /D WIN32 /D _W
INDOWS /D NDEBUG /D _CRT_SECURE_NO_DEPRECATE /D _CRT_SECURE_NO_WARNINGS /D _CRT_
NONSTDC_NO_DEPRECATE /D _CRT_NONSTDC_NO_WARNINGS /D _SCL_SECURE_NO_DEPRECATE /D
_SCL_SECURE_NO_WARNINGS /D __STDC_CONSTANT_MACROS /D __STDC_FORMAT_MACROS /D __S
TDC_LIMIT_MACROS /D _HAS_EXCEPTIONS=0 /D _HAS_EXCEPTIONS=0 /D _HAS_EXCEPTIONS=0
/D "CMAKE_INTDIR=\"MinSizeRel\"" /D _MBCS /Gm- /MD /GS /fp:precise /Zc:wchar_t /
Zc:forScope /GR- /Fo"LLVMX86Disassembler.dir\MinSizeRel\\" /Fd"C:/workspace/llvm
-3.0.src/build/lib/MinSizeRel/LLVMX86Disassembler.pdb" /Gd /TP /wd4146 /wd4180 /
wd4224 /wd4244 /wd4267 /wd4275 /wd4291 /wd4345 /wd4351 /wd4355 /wd4503 /wd4551 /
wd4624 /wd4715 /wd4800 /wd4065 /wd4181 /analyze- /errorReport:prompt ..\..\..\..
\..\lib\Target\X86\Disassembler\X86Disassembler.cpp /Zm1000 /EHs-c- -w14062

A final comment: I talked to some members of the Compiler team responsible for the code that decides if dynamic initialization is necessary and got some information from them i'd like to share.
They agree that the compiler should be creating static initialization for this case (in fact for C++0x it looks like it might be required) and have opened an item internally to try address this deficiency. It's too early to say yet what, if any, release will contain this fix. Regardless, you can count on the next major release of Visual Studio not appearing to hang on this function.

Again, thanks for letting us know you've encountered this problem. Your feedback is valuable is one of the major ways we continue to improve our product with each release.

thanks,
Visual C++ Code Generation and Optimization Team

Thank you. Keep me posted. So far I haven't found a better workaround other than disabling the optimization flag.

I'm still playing around with this, but at lest it appears that the dynamic intiailization is kicking in for the "const" member of the struct. Removing "const" from "EDInstInfo::operandOrders" stop the compiler from emitting the dynamic initializer. The would appear to be the best solution yet.

I need to do some more investigation to see if this "feature" of the compiler is by-design or a bug.

I spent a bit more time on this and it i'm pretty sure its not hang. Compilation just takes a *really* long time. I didn't wait for it to finish though, after 15 minutes the compiler was still in the very early stages of code generation.

I suggested earlier to try and change the array to be statically initialized. However, it's not obvious why the C++ compiler believes it needs to dynamically initalize this data (maybe it is too large?), but the same array can be written in C which doesn't support dynamic initialization. This means that another possible work around is to move the array into a .c file (or use -Tc) to compile it as C code. I tried this and it works well, shaving about 35 seconds off of compiling the same code in C++ with optimizations disabled.

Thanks for reporting this issue. I was able to reproduce the problem and determine that it is with the dynamic initializer for 'instInfoX86'. I'm not yet sure if this is an actual hang or the compiler is just taking an extremely long time (not that there is much of a difference if it won't finish in a reasonable amount of time). The problem is that the dynamic initializer for the array is very large which causes many algorithms within the optimizer to have long running times or other problems.

You're workaround of disabling optimizations for this initializer is probably the best for you. An alternative, if it is possible, is to change the array so that it can be entirely statically initialized which will eliminate the dynamic initializer function. In this vain another alternative is to move the portions of the array that require dynamic initialization to the end of the array. This will also improve compile time by reducing the amount of data that needs to be dynamically initialized (dynamic initialization is required for the entire data structure after the first field that requires dynamic initialization).

Compile time issues with dynamic initializers are known and we have some tentative plans to address them in future releases of Visual Studio. Once again thanks, for letting us know about this and providing a test case so that we could investigate. I’ll post again if this turns out to be more than the usual problems with very large dynamic initializers.

thanks,
VC++ Code Generation and Optimization Team

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)