search for: llvmcodegener

On Tue, 21 Mar 2006, Reid Spencer wrote: > About the only thing I can suggest are: > > 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already > happening with the new Sparc backend that is being developed. Should be > out in 1.7 (Chris?) I wouldn't worry about the SparcV9 backend for your project. > 2. Combine the JIT/Interpreter/ExecutionEngine into one .a

On Tue, May 12, 2009 at 11:55 PM, Chris Lattner <clattner at apple.com> wrote: > Dan, can you add IVUsers.cpp to the appropriate cmakefile? > > -chris > > > On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner <clattner at apple.com> >> wrote: >>> >>> On May 12, 2009, at 10:24 PM,

John Myers <atomicdog.jwm at gmail.com> writes: > I'm looking for some pointers on how to troubleshoot this problem. I'm > trying to write a backend for the AVR. > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a

Hi, everyone. Today I was trying to build LLVM with libc++ and C++11 enabled, and I ran into this: http://stackoverflow.com/questions/10065384/instantiation-of-a-list-with-an-incomplete-type-in-a-typedef 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

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

I am considering using LLVM in a project for a Windows CE where space is at a premium. My jaw dropped when I checked the size of HowToUseJIT.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

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

Hi Eric, Its definitely amusing :) About the only thing I can suggest are: 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already happening with the new Sparc backend that is being developed. Should be out in 1.7 (Chris?) 2. Combine the JIT/Interpreter/ExecutionEngine into one .a I don't know enough about the codegen/target/analysis/ipa stuff to be able to make any

I ran cmake to build the visual studio projects. Then I included my code under the Visual Studio interface, 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

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

Hi, Looking into LLVM for a database query engine project... After downloading the latest source from CVS, it's my first time trying to build LLVM. Following the "Getting Started" instructions, all went well until gmake reported this error while trying to link llc: In function `(anonymous namespace)::BreakCriticalEdges::getAnalysisUsage(llvm::AnalysisUsage&) const':

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T,

This is a known issue with the current PBQP data structures. I'm working on an overhaul of the PBQP allocator at the moment which should address this. - Lang. On Sat, Oct 20, 2012 at 2:08 PM, Benjamin Kramer <benny.kra at gmail.com>wrote: > > On 20.10.2012, at 22:47, Jordan Rose <jordan_rose at apple.com> wrote: > > > Hi, everyone. Today I was trying to build LLVM

Reid, Getting the same error again :-( /usr/gcc/gcc-3.4.3/libexec/gcc/i686-pc-cygwin/3.4.3/collect2.exe -Bdynamic --dl l-search-prefix=cyg -o /usr/build/llvm-2/Debug/bin/llc.exe /lib/crt0.o -L/usr/bu ild/llvm-2/Debug/lib -L/usr/build/llvm-2/Debug/bin -L/usr/gcc/gcc-3.4.3/lib/gcc/ i686-pc-cygwin/3.4.3 -L/usr/gcc/gcc-3.4.3/lib/gcc/i686-pc-cygwin/3.4.3/../../..

> > 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. I was linking with VMCore.lib support.lib

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 >

On 20.10.2012, at 22:47, Jordan Rose <jordan_rose at apple.com> wrote: > Hi, everyone. Today I was trying to build LLVM with libc++ and C++11 enabled, and I ran into this: > > http://stackoverflow.com/questions/10065384/instantiation-of-a-list-with-an-incomplete-type-in-a-typedef > > Basically, PBQP/Graph.h forward-declares classes, then tries to get iterators for

'collect2.exe' is an internal version of 'ld' called by GCC The GCC command line is :- g++ -I/usr/build/llvm-2/tools/llc -I/usr/src/llvm/tools/llc -I/usr/build/llvm-2/ include -I/usr/src/llvm/include -I/usr/build/llvm-2/include -I/usr/src/llvm/incl ude -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W -Wwrite-strings -Wno-unused -g -D_DEBUG -v -o /usr/build/llvm-2/Debug/bin/llc.exe

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 LLVMIPA. If you knew