similar to: [LLVMdev] Most efficient way to count # of intrcutions in a module ?

Hello I have the following scenario, and I am not sure why the performance is so bad (take 30 minutes to complete with very simple generated functions): 1. Create module 2. Do something like EE = EngineBuilder(theModule).setEngineKind(EngineKind::JIT).create(); 3. Create a function in the module: theModule->getOrInsertFunction(..) 4. Execute 1000 times the function using

Hi Gabi, I have no idea why your performances is not as expected with such low level of informations. But, I know that the binary code is cached by the JIT. You can find the code in JIT.cpp to convince yourself : runFunction -> getPointerToFunction ->getPointerToGlobalIfAvailable which returns the native address of the jitted function. You can even try to measure time needed by each

Hi I get huge memory leaks using LLVM IRBuilder (trunk version) Basically I recreate a function over and over again, and pretty sure that my code doesn't cause the leak while(true) { Function *fn = module->getFunction(name); if (fn) fn->eraseFromParent(); fn = cast<Function>(module->getOrInsertFunction(name, fnType)); fillFunction(fn); //Fill function with

Reid, Thanks! You were right! Changing the code to: float (*theF)(float) = (float (*)(float)) EE -> getPointerToFunction(f); float retVal = theF(arg1); made the difference. Now it is dozens of times faster! I don't really understand the cause though.. Why doesn't ExecutionEngine cope well with "define float @someFunc(float %x)" and needs this trick ? (but copes well with

Probably because the integer version of the prototype is special-cased. The problem is that the JIT has a C function pointer of an arbitrary type that it only finds out about at runtime. Normally, if you call a function pointer with a known type, your compiler will generate the proper calling code and allocate the arguments in registers or on the stack. However, doing that inside the JIT would

Hi, The following arbitrary example makes the code generators to get stuck (llvmc won't return from command line, Jit won't return from function call) Basically it is a CFG with circles, (the function will return by comparing a branch counter to a threshold on runtime - see the "Brancher" blocks below) Any idea what goes wrong? Is it a bug in llvm ? ; ModuleID =

Hi all, This question was probably asked million times before, but I wasted few hours and didn't find the solution.. What is the best way to traverse a large array (say size of million) with GetElementPtr The problem with the following code, is that it forces you to create million constant index values: intVars = new AllocaInst(Type::getInt32Ty(ctx), allocaSize, "intVars",

> PS: Maybe not for x86 long double though. Right, so how to make x86 double displayed in decimal ? -- Regards, Gabi http://bugspy.net

Hi Christoph I am compiling for x86-64. This error happens randomly (at least it appears that way) and rarely. About every few thousand runs -- Regards, Gabi http://bugspy.net

I get this message once in a while and llvm exits the program. What might be the cause ? llvm version: svn host: Linux x86_64 -- Regards, Gabi http://bugspy.net

Are you calling llvm_shutdown() at the end of your program? You should. valgrind reports "possible" leaks when it finds a pointer pointing inside a memory block (as opposed to at the first byte), and LLVM uses those a lot. llvm_shutdown() will free a lot of that memory, including the LLVMContext, which should remove any false leaks you might be seeing. On the other hand, the

The xentrace_format script doesn''t work on x86/64. Python pads the input structure because the first field is 32 bits and the next is 64 bits, whereas x86-32 doesn''t pad. The quick fix is to read the cpu id separately as a 32bit value, then read the rest of the trace record. Here is a little patch that does that. Tested on x86/32 SMP and x86/64. Signed-off-by: Rob Gardner

I think I found the cause. It appears that FP operations and functions (I used combinations of CreateFMulL CreateFAdd and CreateFSub ) is MUCH slower than their integer equivalents. I mean really slower (20x slower or even more) Can It be the cause ? Does the FP binary ops are so slow ? -- Regards, Gabi http://bugspy.net

Is there a way to make the printer to display float values in decimal form instead of the cryptic 0x... ? -- Regards, Gabi http://bugspy.net

How does one move instructions from one basic block to another? I tried this: (IB is an Instruction* as is current_last, current_BB is a BasicBlock*) IB->getParent()->getInstList().remove(IB); current_BB->getInstList().insert(current_last, IB); and I get this assertion: Assertion `V->getParent() == 0 && "Value already in a container!!"' failed.

> Compiling InstrSelectorEmitter.cpp > InstrSelectorEmitter.cpp: In member function `virtual void > llvm::InstrSelectorEmitter::run(std::ostream&)': > InstrSelectorEmitter.cpp:1295: internal compiler error: in > convert_from_eh_region_ranges_1, at except.c:1159 > Please submit a full bug report, GCC 3.3.2 is not compatible with LLVM, sorry! -Chris > with

Hi LLVMers, the example attached I have used to prove that JIT and some visible optimizations are really invoked. Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 on my Athlon XP 1500. Nice. P.S. guys, no fears, I don't plan to flood the cvs repository with my "brilliant" examples ;) --- Valery A.Khamenya -------------- next part -------------- An

On Tue, 17 Aug 2004, Reid Spencer wrote: > That's pretty cute actually. Do you want this "brilliant" :) example in the cvs > repository? I'd be happy to put it in. Here's an idea: how about we take the ModuleMaker, Valery's previous example, and this one and put them all in one "small examples" project? -Chris > Valery A.Khamenya wrote: > >

Valery, That's pretty cute actually. Do you want this "brilliant" :) example in the cvs repository? I'd be happy to put it in. Reid. Valery A.Khamenya wrote: > Hi LLVMers, > > the example attached I have used to prove that JIT and some visible > optimizations are really invoked. > > Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 >

On Mon, Sep 5, 2016 at 3:20 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Sun, Sep 4, 2016 at 1:06 PM, Simona Simona via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello, >> >> I'm trying to add a new instruction after a given instruction in a basic >> block. >> Until LLVM 3.7, I was using the following code: