similar to: [LLVMdev] cross-compilation

Is there a facility with which we may automagically create a "fake" exit node, one that is the target of all BasicBlocks ending in return. This would be very helpful to IP dataflow analysis... Dave

On Fri, 29 Nov 2002, Anand Shukla wrote: > There is a pass "UnifyFunctionExitNodes()" (you can add it to AnalysisUsage > of your pass) that does the trick. Yup, just like Anand says, this pass will make it so that there is at most one exit node from the function, which you can use for your analysis (it will even tell you which BB that is too). Note that a function may _not_ have

I use the following code to do the depth first search on the DSGraph. And I always got this error message. Couldn't figure out what's wrong. Could you please let me know? Besides, I really have no idea about what those functions do. Is there any documentation about DSGraph functions besides the pool allocation paper? Thanks, xiaodong Code: for( df_iterator<DSNode*> I =

LLVM, What do I pass into the DSG in order to access the globals vector of functions that a function pointer may be calling. The code: CallInst *calli = dynamic_cast<CallInst*>(*i); std::vector<GlobalValue*> funcVect = theGraph.getNodeForValue(calli->getCalledFunction()).getNode()->getGlobals(); Doesn't appear to work... getCalledFunction() returns 0 Dave On Fri, 6 Dec

cvs co llvm ... cd llvm; ./configure --with-llvmgccdir=<llvmgccdir>; make ... Compiling llvmAsmParser.cpp Linking /home/dcrowe/llvm/llvmcvs/llvm/lib/Debug/asmparser.o make[2]: Leaving directory `/home/dcrowe/llvm/llvmcvs/llvm/lib/AsmParser' make[2]: Entering directory `/home/dcrowe/llvm/llvmcvs/llvm/lib/Bytecode' make[2]: *** No rule to make target `all'. Stop. make[2]:

LLVM, When we recompile, is it possible to "make" only one of the tools, or at least relink only the tools whose object files have changed? Thanks Dave

Hi list, The short version of my question: Is it easy to make a lightweight (read: small in size) linker loader for code produced by the llvm jit. Does it even make sense to do so? The longer version: Suppose I have some llvm bytecode module A, and I want to load and use that code in some runtime. The two obvious ways to do that are a) use the LLVM jit, or b) compile the module into a dynamic

Tanya Lattner wrote: > > Everything builds fine on sparc. The configure script needs to be fixed > though (see previous email). I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH. Can you verify that the configure script works for you without the --with-f2c option?

Hi, I downloaded and installed the front-end (llvm-gcc 4), and downloaded, configured, and built llvm-2.0 using -prefix=[myllvmPath] and -with-llvmgccdir=[llvm-gccPath] When I try to use sparc as target, llvm-gcc does not recognize it. I used -march=sparc and it gives two errors: "bad value (sparc) for -march= switch" "bad value (sparc) for -mtune= switch" I used

Hi all, I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

Although the process of porting the LLVM backend to a new architecture looks pretty straightforward (and is very well documented) there's a frontend issue that I'm not clear on: How do we to tell the frontend about implementation-defined constants like integer width? In other words, when llvm-gcc does a promote-to-integer operation, this acts differently if the target architecture

Hi all, I am trying to build a cross compiler for Sparc on x386 host. I tried to run configure with configure --enable-targets=sparc or with configure --target=sparc but in both cases I got llvm compiler for x86 target. Is there a way to build a cross compiler for Sparc (or ARM)? Thanks. -- Fima Rabin -------------- next part -------------- An HTML attachment was

> Note that compiling glibc with LLVM does not give you a solution to THIS > problem: you'd still have to write a new backend for your ISA. There is > currently a Sparc backend and an X86 backend. Depending on how similar > your architecture is to one or the other, you might be able to leverage > existing code. Take a look at llvm/lib/Target/{Sparc,X86}, though the > X86

Hi, I have a question about x86 code quality. I have run a few benchmarks and compared the running time of executables created by LLVM to executables created by gcc. It appears that code generated by LLVM is x1.5 - x3 times slower than code generated by gcc, for the x86 For some of the benchmarks the linear scan regalloc works. When it does, results are in the x1.0 - 1.5 range. Unfortunately,

On 09/02/2010, at 3:57 AM, Chris Lattner wrote: > On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: >> Firstly, the BNE/BA pair should be reduced to a BE (I assume this is the responsibility of AnalyzeBranch and friends that you mention). > > Right. Implementing AnalyzeBranch will allow a bunch of block layout and branch optimizations to happen. > >> However I still

On 02/10/2010 01:31 AM, Nathan Keynes wrote: > On 09/02/2010, at 3:57 AM, Chris Lattner wrote: > > >> On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: >> >>> Firstly, the BNE/BA pair should be reduced to a BE (I assume this is the responsibility of AnalyzeBranch and friends that you mention). >>> >> Right. Implementing AnalyzeBranch

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

On Tue, 22 Feb 2005, Vikram S. Adve wrote: >> The second issue is that we need to do redundancy elimination and hoisting >> on operations that are only exposed once instruction selection is >> performed. Getelementptr expansion is just ONE particular case of this, >> but it can happen with any instructions (including the use of large integer >> (or any FP)

-----Original Message----- From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu] Sent: Sunday, January 25, 2004 7:16 AM To: Joseph E. Grzywacz Subject: RE: [LLVMdev] Basic Blocks: Bytecode -> Native Code [Joseph, I'm sending this again because I didn't copy the list the first time.] Yes, this is true for the Sparc back-end. In fact, it is a fundamental assumption that is relied on by

> Are you guys interested in contributing this back to LLVM? It would be > great if so. We can set up cvs commit access and other stuff as needed > when this gets going. I am. A cvs account will help a lot. Thanks. I am currently "translating" the sparc back end. When I have a decent skeleton (remove all sparc code for example) I will email it. What paperwork is necessary