search for: llvmcodegen

...of them. This would allow people to link just the JIT or just the interpreter into their apps, instead of always having both or none. > I don't know enough about the codegen/target/analysis/ipa stuff to be > able to make any suggestions. Perhaps Chris can shed some light. >> LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a >> libLLVMTransformUtils.a libLLVMipa.a Codegen and SelectionDAG can be merged, either physically in the source base or treated as one thing in your code. CodeGen should depend on Target, but not the other way around. LLVMIPA should...

...d to the LLVMAnalysis library, fixed some of those errors, but there are more still. Patch is attached for the IVUsers.cpp add to the CMakeLists.txt file. 32> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.exp 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2001: unresolved external symbol "public: virtual void __thiscall llvm::PEI::getAnalysisUsage(class llvm::AnalysisUsage &)const " (?getAnalysisUsage at PEI@llvm@@UBEXAAVAnalysisUsage at 2@@Z) 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : er...

...included on the build. This means that either you update the file manually or run the build with MSYS passing -DLLVM_TARGETS_TO_BUILD=all on the cmake command line. The manual update would consist on adding this lines to the above mentioned file: set(MSVC_LIB_DEPS_LLVMAVRAsmPrinter LLVMAsmPrinter LLVMCodeGen LLVMCore LLVMMC LLVMAVRInfo LLVMSupport LLVMSystem LLVMTarget) set(MSVC_LIB_DEPS_LLVMAVRCodeGen LLVMCodeGen LLVMCore LLVMMC LLVMAVRInfo LLVMSelectionDAG LLVMSupport LLVMSystem LLVMTarget) set(MSVC_LIB_DEPS_LLVMAVRInfo LLVMSupport) which uses MSP430 as a template and supposses that your target is n...

...f Basically, PBQP/Graph.h forward-declares classes, then tries to get iterators for std::lists of those classes. This is technically undefined behavior. I tried fudging with the order of declarations for a while, but gave up after realizing there's not an easy way out. Is anyone else building LLVMCodeGen with libc++ and C++11? Is anyone else seeing this? Thanks, Jordan

Reid added some nice inter-library dependency data to utils/llvm- config/LibDeps.txt. There are three sets of circular dependencies between LLVM libraries. If you use any library from one of these sets, you may need to pull in the rest: LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a libLLVMTransformUtils.a libLLVMipa.a LLVMSparcV9.o LLVMSparcV9InstrSched.o LLVMSparcV9ModuloSched.o LLVMSparcV9RegAlloc.o LLVMExecutionEngine.o LLVMInterpreter.o LLVMJIT.o The first set is the most problematic: It includes four *...

...eJIT.exe (VC++ Win32 debug): 15.4 MB! The release build of HowToUseJIT is "only" 3.39 MB, but this is still 85% larger than the binary to which I was thinking of adding LLVM. The top ten LLVM libraries (Win32 *.lib) are pretty huge: Release Bld Debug Bld Name 24,510,490 71,038,240 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....

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

...Kidd wrote: > Reid added some nice inter-library dependency data to utils/llvm- > config/LibDeps.txt. > > There are three sets of circular dependencies between LLVM libraries. > If you use any library from one of these sets, you may need to pull > in the rest: > > LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a > libLLVMTransformUtils.a libLLVMipa.a > > LLVMSparcV9.o LLVMSparcV9InstrSched.o LLVMSparcV9ModuloSched.o > LLVMSparcV9RegAlloc.o > > LLVMExecutionEngine.o LLVMInterpreter.o LLVMJIT.o > > The first set is...

...erface, but I placed my code separate from the CodeGen code. Visual studio was smart enough to compile and link in my code into the CodeGen library. Thus, I did not need to add my code into the same directory as the CodeGen files, and I did not need to change the CMakeList.txt. The offical name is LLVMCodeGen. However, the "opt.obj" and "bugpoint.obj" cannot find the reference function "llvm::createJDKunkRegisterAllocator." I added this file to the header described previously. I implemented it, in my RegAllocJDKunk.cpp file. Jeff Kunkel On Fri, Oct 15, 2010 at 1:43 PM,...

...r\LLVMAsmParser.vcproj" LLVMAsmPrinter, "lib\CodeGen\AsmPrinter\LLVMAsmPrinter.vcproj" LLVMBitReader, "lib\Bitcode\Reader\LLVMBitReader.vcproj" LLVMBitWriter, "lib\Bitcode\Writer\LLVMBitWriter.vcproj" LLVMCodeGen, "lib\CodeGen\LLVMCodeGen.vcproj" LLVMCore, "lib\VMCore\LLVMCore.vcproj" LLVMExecutionEngine, "lib\ExecutionEngine\LLVMExecutionEngine.vcproj" LLVMInstCombine, "lib\Transforms\InstCombine\LLVMInstCombine.vcproj"...

...-linux/3.4.3 -L/usr/lib/gcc/i386-redhat-linux/3.4.3 -L/usr/lib/gcc/i386-redhat-linux/3.4.3/../../.. /home/kh/llvm/obj/tools/llc/Debug/llc.o /home/kh/llvm/obj/Debug/lib/LLVMCBackend.o /home/kh/llvm/obj/Debug/lib/LLVMX86.o /home/kh/llvm/obj/Debug/lib/LLVMSelectionDAG.o /home/kh/llvm/obj/Debug/lib/LLVMCodeGen.o /home/kh/llvm/obj/Debug/lib/LLVMBCReader.o /home/kh/llvm/obj/Debug/lib/LLVMBCWriter.o /home/kh/llvm/obj/Debug/lib/LLVMCore.o /home/kh/llvm/obj/Debug/lib/LLVMbzip2.o --export-dynamic -lLLVMTarget -lLLVMipa -lLLVMTransforms -lLLVMScalarOpts -lLLVMAnalysis -lLLVMTransformUtils -lLLVMSupport -lLLV...

..../../bin/llvm-mc -rdynamic ../../lib/libLLVMAVRCodeGen.a ../../lib/libLLVMAVRAsmPrinter.a ../../lib/libLLVMAVRInfo.a ../../lib/libLLVMMC.a ../../lib/libLLVMSupport.a ../../lib/libLLVMSystem.a -ldl ../../lib/libLLVMSelectionDAG.a ../../lib/libLLVMAnalysis.a ../../lib/libLLVMAsmPrinter.a ../../lib/libLLVMCodeGen.a ../../lib/libLLVMCore.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMTransformUtils.a ../../lib/libLLVMSupport.a ../../lib/libLLVMSystem.a ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `AVRTargetMachine': /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.cpp:48:...

...-declares classes, then tries to get > iterators for std::lists of those classes. This is technically undefined > behavior. I tried fudging with the order of declarations for a while, but > gave up after realizing there's not an easy way out. > > > > Is anyone else building LLVMCodeGen with libc++ and C++11? Is anyone > else seeing this? > > I was hitting this problem a while ago, but it's not reproducible when > compiling llvm with clang trunk and libc++ trunk. > > - Ben > _______________________________________________ > LLVM Developers mailing list...

...InstrSched. o /usr/build/llvm-2/Debug/lib/LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/L LVMX86.o /usr/build/llvm-2/Debug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/L LVMAlpha.o /usr/build/llvm-2/Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LL VMSelectionDAG.o /usr/build/llvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Deb ug/lib/LLVMScalarOpts.o /usr/build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/ll vm-2/Debug/lib/LLVMBCWriter.o /usr/build/llvm-2/Debug/lib/LLVMCore.o /usr/build/ llvm-2/Debug/lib/LLVMbzip2.o --export-dynamic -lLLVMTarget -lLLVMipa -lLLVMTrans forms -lLLVMAnalysis -lLLVMTrans...

...o > the linker for including them on the final executable. I was linking with VMCore.lib support.lib System.lib Analysis.lib CodeGen.lib Target.lib Transforms.lib and I'm now linking with LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib LLVMTransformUtils.lib LLVMAsmPrinter.lib > > In my opinion, we have to choose one way and remove the other one. If > > it helps, you can put in the win32 directory the result of CMake, > > On the release tarball? It seems a good idea (as far as someone >...

On Jul 23, 2010, at 10:24 AM, David Piepgrass wrote: > The top ten LLVM libraries (Win32 *.lib) are pretty huge: > > Release Bld Debug Bld Name > 24,510,490 71,038,240 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,06...

...ly, PBQP/Graph.h forward-declares classes, then tries to get iterators for std::lists of those classes. This is technically undefined behavior. I tried fudging with the order of declarations for a while, but gave up after realizing there's not an easy way out. > > Is anyone else building LLVMCodeGen with libc++ and C++11? Is anyone else seeing this? I was hitting this problem a while ago, but it's not reproducible when compiling llvm with clang trunk and libc++ trunk. - Ben

...InstrSched.o /usr/build/llvm-2/Debug/lib /LLVMSparcV9LiveVar.o /usr/build/llvm-2/Debug/lib/LLVMX86.o /usr/build/llvm-2/De bug/lib/LLVMPowerPC.o /usr/build/llvm-2/Debug/lib/LLVMAlpha.o /usr/build/llvm-2/ Debug/lib/LLVMIA64.o /usr/build/llvm-2/Debug/lib/LLVMSelectionDAG.o /usr/build/l lvm-2/Debug/lib/LLVMCodeGen.o /usr/build/llvm-2/Debug/lib/LLVMScalarOpts.o /usr/ build/llvm-2/Debug/lib/LLVMBCReader.o /usr/build/llvm-2/Debug/lib/LLVMBCWriter.o /usr/build/llvm-2/Debug/lib/LLVMCore.o /usr/build/llvm-2/Debug/lib/LLVMbzip2.o -Wl,--export-dynamic -L/usr/build/llvm-2/Debug/lib -lLLVMTarget -lLLVMipa -lLLV MTra...

Mondada Gabriele <g.mondada at etel.ch> writes: > I just moved to the CMake solution. By the way, the generated libs > haven't the same names. Which ones? The only difference is that we now generate .lib files where .obj were generated on the past, and require a parameter to be passed to the linker for including them on the final executable. > In my opinion, we have to choose

On Mar 21, 2006, at 11:23 PM, Chris Lattner wrote: >>> LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a >>> libLLVMTarget.a >>> libLLVMTransformUtils.a libLLVMipa.a > > CodeGen should depend on Target, but not the other way around. > LLVMIPA should depend on LLVMAnalysis, but certainly nothing in the > list should depend on L...