similar to: [LLVMdev] Missing Functions in C-Bindings

Is it kosher to include vim mode line comments inside of LLVM source files? I would like to do this inside of the MicroBlaze backend to ensure that tabs are expanded into exactly two spaces. I see that right now the following files have these vim mode line comments: include/llvm/ADT/SetVector.h lib/Archive/ArchiveInternals.h lib/Linker/LinkModules.cpp lib/Transforms/IPO/DeadTypeElimination.cpp

On the trunk version of LLVM I am getting the following build error on Snow Leopard (v10.6.2): llvm[3]: Building X86.td DAG instruction selector implementation with tblgen Assertion failed: (LHS->ID != RHS->ID), function operator(), file /Users/peckw/Projects/llvm/llvm-pristine/utils/TableGen/DAGISelEmitter.cpp, line 183. ... <cut - see full_stack_trace.txt> 0. Program arguments:

Recently I have been getting a build failure while trying to link lli when performing a cmake based build. The failure is: Undefined symbols: "_LLVMLinkInMCJIT", referenced from: (anonymous namespace)::ForceMCJITLinking::ForceMCJITLinking()in lli.cpp.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [bin/lli] Error 1 I have fixed this with the

Just for informational purposes on a smaller system (Core 2 Duo MacBook Pro): make none X86.td X86InstrInfo.cpp real 11.568 217% 76.283 177% 34.435 169% user 7.726 141% 70.659 100% 25.608 116% sys 3.234 111% 3.992 100% 6.438 104% make -j2 none X86.td X86InstrInfo.cpp real 7.7346 145% 43.138 100% 25.77 127% user 7.6072 139% 70.414 100% 26.589 121% sys 3.2492 111% 3.984 100%

> Date: Wed, 26 Oct 2011 11:52:50 -0700 > From: Tanya Lattner <lattner at apple.com> > Subject: [LLVMdev] Release Notes: Volunteers needed > We need some volunteers to help with the 3.0 release notes. Traditionally, Chris has been the one to go > through all the commits (6 months worth!) and come up with a concrete list of things that have changed in 3.0. > Ideally,

On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > The rest is already in Target, so LGTM :-). Move the > MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from > there. Will do. Again, thank for taking a look at this. -- Wesley Peck University of Kansas SLDG Laboratory

Look I have written a PRE pass. opt is running that pass. I have included my pass name there in include/llvm/Support/StandardPasses.h file. To do that, I have got some error. Because it also requires the definition of the pass in some other file also. I observed how gvn pre pass is added to the pass list. I had followed the same way, but failed. Cna you kindly tell what needs to be done in this

Hi all, I can compile LLVM+clang (from svn 2.8 branch, fyi) just fine with gcc 4.4.5 and 4.5.1 on Linux/amd64 just fine, and I did successfully built LLVM+clang on Solaris10/amd64 (32bit built) just fine with gcc 3.3, too. However, when it comes to compiling my *own* project that builds atop of LLVM, I'm getting a strange compilation error when using GCC 4.5.1 but *NOT* when using GCC 4.4.5

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where

On Fri, Nov 19, 2010 at 12:59 PM, Wesley Peck <peckw at wesleypeck.com> wrote: > On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > >> The rest is already in Target, so LGTM :-). Move the >> MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from >> there. > > Will do. Again, thank for taking a look at this. Heads up: I just lifted some code

For a while now I have noticed that when I build LLVM using CMake on my OS X machine there are two dynamically linked libraries, BugpointPasses and LLVMHello, that are built with the extension ".so" instead of the extension ".dylib". This has been causing four test cases to fail when running "make check". The attached patch modifies add_llvm_loadable_module in the

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is

Soumya_Prasad_Ukil wrote: > Look I have written a PRE pass. opt is running that pass. I have > included my pass name there in include/llvm/Support/StandardPasses.h > file. To do that, I have got some error. Because it also requires the > definition of the pass in some other file also. I observed how gvn pre > pass is added to the pass list. I had followed the same way, but failed.

On Feb 24, 2011, at 8:14 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: > >>> class CodeGenOpt { >>> ... >>> public >>> getOptLevel() ...; >>> getFPLevel() ...; >>> getMemLevel() ...; >>> }; >>> >>> Does this sound reasonable? >> >> I don't think that this is

Dale is totally right, all of these blocks disappear in later target-dependent optimizations. I have not thought about that since eliminating these blocks requires no target-dependent information. However, I guess it is not worth eliminating them earlier. John, I tried your advice and executed opt (after -O3) again with -mergereturn and -simplifycfg: The -mergereturn pass introduces another

Soumya_Prasad_Ukil wrote: > Pls help. You didn't say what was actually running the passes. (llvm-gcc? clang? opt -some -passes?) What you probably want is to modify one of the lists in include/llvm/Support/StandardPasses.h. Nick > > On 21 August 2010 17:32, Soumya_Prasad_Ukil <ukil.soumya at gmail.com > <mailto:ukil.soumya at gmail.com>> wrote: > > I have

Larry, On Wed, Aug 11, 2010 at 4:55 PM, Larry Gritz <lg at larrygritz.com> wrote: > I have a whole slew of questions about optimization passes. Answers to any > or all would be extremely helpful: > > How important are doInitialization/doFinalization? Most of the passes do not use them. > I can't detect any difference if I use them or not. Say, if you are writing

On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote: > I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project. I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be

On Apr 18, 2011, at 6:46 AM, Alexander Potapenko wrote: > Hi all, > > we're working on compile-time instrumentation for ThreadSanitizer (a > data race detector, see http://code.google.com/p/data-race-test and > http://code.google.com/p/data-race-test/wiki/CompileTimeInstrumentation), > which is implemented as an opt plugin that is ran for each client > C/C++ module we

On Tue, Jul 23, 2013 at 5:53 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Yes. What you are seeing are the platform checks, where the build system > looks for the presence of functions, headers, etc and then generates a > configuration file with that information. I've been meaning to cut down on the number of these because they are super slow and wasteful. Some of them are