search for: llvmx86codegen

...architecture is the Intel Xeon Phi (KNC) accelerator in a native execution model. When cross-compiling LLVM (3.4 RC1) for Xeon Phi with CMake following the Intel guidelines (for general cross-compilation), the compilation process stops with [ 88%] Building CXX object lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o [ 88%] Building CXX object lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86InstrInfo.cpp.o [ 88%] Building CXX object lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86JITInfo.cpp.o /tmp/icpcI3Tb9Aas_.s: Assembler messages: /tmp/icpcI3Tb9Aas_.s:48: Error: `movaps' is n...

...xhibit this mismatch. A repeat of the rc2 build repeated the mismatch. I diff'd the disassembly between phase 2 and phase 3 and the difference is the same on both builds. The difference follows: # diff x86isel_p{2,3}.s 2c2 < Phase2/Release/llvmCore-8.0.0-rc2.obj/lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o: file format elf64-x86-64 --- > Phase3/Release/llvmCore-8.0.0-rc2.obj/lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o: file format elf64-x86-64 121757c121757 < 863: 48 8b 84 24 e0 05 00 mov 0x5e0(%rsp),%rax --- > 863:...

...rl hacking skills aren't up to getting --libnames and --libfiles to work as well as --libs. I discovered one other thing that was causing me problems on MinGW: if I use the msys.bat to open a terminal llvm-config inserts double slashes at the start of any absolute path it generates (e.g. //lib/LLVMX86CodeGen.o) - this breaks g++. If I do the same thing from a DOS prompt running bash, slashes don't get doubled and everything works fine. Thanks once again Óscar and Anton. Duncan Pierce

...Boxem <vanboxem.ruben at gmail.com> Date: 2010/12/31 Subject: LLVM on Windows MSVC 10 To: cfe-dev at cs.uiuc.edu Hi, I'm trying to build svn LLVM with Visual Studio 2010: cd build cmake .. -G"NMake Makefiles" nmake and several link steps fail due to a missing symbol: > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved external symbol X86CompilationCallback referenced in function "public: virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6A...

...uiuc.edu >> >> >> Hi, >> >> I'm trying to build svn LLVM with Visual Studio 2010: >> >> cd build >> cmake .. -G"NMake Makefiles" >> nmake >> >> and several link steps fail due to a missing symbol: >> >> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved >> > external symbol X86CompilationCallback referenced in function "public: >> > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void >> > * (__cdecl*)(void *)))(void)" >> > (?g...

Hi I am modifying X86RetpolineThunks.cpp. X86RetpolineThunks.cpp 's location is llvm-src/lib/Target/X86. Which target should I use , next time use clang test.c , I can see the difference . I found that "make llc" doesn't work. And either "make LLVMX86CodeGen" doen't work. "make clang" waste a lot of time, even -j64. Every time modifying the file of machine function pass , I have to wait for 1 min. It drive me crazy. Which "target" should use to "make" when developing machine function pass ? Or is there other...

...LLVMTransformUtils, "lib\Transforms\Utils\LLVMTransformUtils.vcproj" LLVMX86AsmParser, "lib\Target\X86\AsmParser\LLVMX86AsmParser.vcproj" LLVMX86AsmPrinter, "lib\Target\X86\AsmPrinter\LLVMX86AsmPrinter.vcproj" LLVMX86CodeGen, "lib\Target\X86\LLVMX86CodeGen.vcproj" LLVMX86Disassembler, "lib\Target\X86\Disassembler\LLVMX86Disassembler.vcproj" LLVMX86Info, "lib\Target\X86\TargetInfo\LLVMX86Info.vcproj" LLVMipa, "lib\Analysis\IPA\LLVMipa.vcp...

...Intel Xeon Phi (KNC) > accelerator in a native execution model. When cross-compiling LLVM (3.4 > RC1) for Xeon Phi with CMake following the Intel guidelines (for general > cross-compilation), the compilation process stops with > > [ 88%] Building CXX object lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/ > X86ISelLowering.cpp.o > [ 88%] Building CXX object lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/ > X86InstrInfo.cpp.o > [ 88%] Building CXX object lib/Target/X86/CMakeFiles/ > LLVMX86CodeGen.dir/X86JITInfo.cpp.o > /tmp/icpcI3Tb9Aas_.s: Assembler messages: > /tmp/icpcI3Tb...

...inter.o /home/maurice/installation/llvm/Debug/lib/LLVMPowerPCCodeGen.o /home/maurice/installation/llvm/Debug/lib/LLVMSparcCodeGen.o /home/maurice/installation/llvm/Debug/lib/LLVMSparcAsmPrinter.o /home/maurice/installation/llvm/Debug/lib/LLVMX86AsmPrinter.o /home/maurice/installation/llvm/Debug/lib/LLVMX86CodeGen.o is not portable! I haven't noticed any ill-effects. Is this a harmless warning or does it need to be fixed? I'm on Linux/Fedora 9, x86-64. Kind regards, Maurice -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev...

Hello, Duncan > I discovered one other thing that was causing me problems on MinGW: if I use the > msys.bat to open a terminal llvm-config inserts double slashes at the start of > any absolute path it generates (e.g. //lib/LLVMX86CodeGen.o) - this breaks g++. That's strange, never seen this before. Do you have two different version of perl installed? (for example, one msys DTK and another one - standalone ActivePerl, etc.) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State Un...

...] Built target llvm-dis Scanning dependencies of target llc [ 93%] Building CXX object tools/llc/CMakeFiles/llc.dir/llc.cpp.o Linking CXX executable ../../bin/llc /usr/bin/ld: error in ../../lib/./LLVMX86AsmPrinter.o(.eh_frame); no .eh_frame_hdr table will created. /usr/bin/ld: error in ../../lib/./LLVMX86CodeGen.o(.eh_frame); no .eh_frame_hdr table will be created. [ 93%] Built target llc Scanning dependencies of target llvm-ranlib Scanning dependencies of target lli [ 95%] Building CXX object tools/lli/CMakeFiles/lli.dir/lli.cpp.o Linking CXX executable ../../bin/lli /usr/bin/ld: error in ../../lib/./LLV...

...40 LLVMCodeGen.lib 21,084,666 56,724,338 LLVMCore.lib 14,624,218 37,070,488 LLVMAnalysis.lib 11,987,202 30,711,450 LLVMScalarOpts.lib 8,600,668 23,837,478 LLVMSelectionDAG.lib 8,634,324 23,802,952 LLVMTransformUtils.lib 8,347,134 20,840,744 LLVMipo.lib 5,061,702 11,028,744 LLVMX86CodeGen.lib 3,857,612 9,270,012 LLVMInstCombine.lib 3,330,608 7,820,760 LLVMSupport.lib The binaries are vastly larger than the source code; for example, everything in lib/CodeGen is 3.63 MB and everything in lib/VMCore is 907 KB. This is quite different than my typical experience; my own C++ so...

...gt; writes: >>> I'm trying to build svn LLVM with Visual Studio 2010: >>> >>> cd build >>> cmake .. -G"NMake Makefiles" >>> nmake >>> >>> and several link steps fail due to a missing symbol: >>> >>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved >>> > external symbol X86CompilationCallback referenced in function "public: >>> > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void >>> > * (__cdecl*)(void *)))(void)" >&...

...ect: LLVM on Windows MSVC 10 > To: cfe-dev at cs.uiuc.edu > > > Hi, > > I'm trying to build svn LLVM with Visual Studio 2010: > > cd build > cmake .. -G"NMake Makefiles" > nmake > > and several link steps fail due to a missing symbol: > > > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved > external symbol X86CompilationCallback referenced in function "public: > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void > * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm...

Hi, attached is a patch to improve including targets other than X86 in CMake MSVC builds. When adding libs to link, rather than always using LLVMX86CodeGen and LLVMX86AsmPrinter, it grabs the correct ones. It also adds "force-link-ints" to the various TargetMachine cpp files, as well as X86AsmPrinter and PPCAsmPrinter. These are needed to be able to encourage the Win32 linker to include those libs (even though they're otherwise unrefere...

...). I'm falling at the last hurdle though when it comes to the final link: 1>------ Build started: Project: Fibonacci, Configuration: Release x64 ------ 1> Creating library C:/llvm-2.7-src/build/lib/Release/Fibonacci.lib and object C:/llvm-2.7-src/build/lib/Release/Fibonacci.exp 1>LLVMX86CodeGen.lib(X86JITInfo.obj) : error LNK2019: unresolved external symbol X86CompilationCallback referenced in function "public: virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAX...

Hi Evan, Sorry for the delayed reply. We've compiled llvm on Linux with only the x86 target, which produced an lli executable that's about 5.5MB. The LLVMX86CodeGen.o alone is 1.7MB. We've configured with --disable-assertions --enable-optimized --enable-targets=x86 --disable-debug-runtime --enable-bindings=none --disable-ltdl-install --disable-shared --enable-static Are there any tips on making them even smaller? It seems that the ARM backend would be s...

...stallation/llvm/Debug/lib/LLVMPowerPCCodeGen.o > /home/maurice/installation/llvm/Debug/lib/LLVMSparcCodeGen.o > /home/maurice/installation/llvm/Debug/lib/LLVMSparcAsmPrinter.o > /home/maurice/installation/llvm/Debug/lib/LLVMX86AsmPrinter.o > /home/maurice/installation/llvm/Debug/lib/LLVMX86CodeGen.o is not > portable! > > I haven't noticed any ill-effects. Is this a harmless warning or does it > need to be fixed? > > I'm on Linux/Fedora 9, x86-64. The warnings are harmless, but regardless libLTO shouldn't be trying to build on any platform except Darwin....

...gt; >> $ cd $BUILD_DIR >> $ grep -i lto CMakeCache.txt | grep ^[A-Z] >> [ OUTPUT ] >> LLVMLTO_LIB_DEPENDS:STATIC= >> LLVM_ENALBLE_LTO:UNINITIALIZED=ON >> LLVM_TOOL_LLVM_LTO_BUILD:BOOL=ON >> LLVM_TOOL_LTO_BUILD:BOOL=ON >> LTO_LIB_DEPENDS:STATIC=general;LLVMX86CodeGen;general;LLVMX86AsmPrinter;general;LLVMX86AsmParser;general;LLVMX86Desc;general;LLVMX86Info;general;LLVMX86Disassembler;general;LLVMCore;general;LLVMLTO;general;LLVMMC;general;LLVMMCDisassembler;general;LLVMSupport;general;LLVMTarget; >> COMPILER_RT_HAS_FNO_LTO_FLAG:INTERNAL=1 >> LLVM_TO...

...lib/LLVMPowerPCAsmPrinter.o /home/nicholas/llvm-commit/Debug/lib/LLVMPowerPCCodeGen.o /home/nicholas/llvm-commit/Debug/lib/LLVMSparcCodeGen.o /home/nicholas/llvm-commit/Debug/lib/LLVMSparcAsmPrinter.o /home/nicholas/llvm-commit/Debug/lib/LLVMX86AsmPrinter.o /home/nicholas/llvm-commit/Debug/lib/LLVMX86CodeGen.o is not portable! If we're going to build a .so file, we need those .o's to be built with -fPIC. As far as I can see, configuring LLVM with --enable-pic actually does that already, so perhaps we can make it the default. But that warning isn't about PIC, it's about the fact that...