similar to: [LLVMdev] JITing code with indirect branch in LLVM 2.7

I am seeing the following assertion in leak detector. /llvm/lib/VMCore/LeakDetector.cpp:43: void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' failed. I am creating a list of instructions using BuildMI() and adding them to a basic block using BB->insert(). I am seeing this

Hello, I am writing a MachineFunction pass that converts vector instructions to a sequence of scalar instructions. First, I go through the function and look for vector registers. For each vector register, I create a set of corresponding scalar registers using createVirtualRegister() function and put it in a map. Then I go through the function and replace vector instructions.The basic structure of

On Wed, Jun 3, 2009 at 5:10 PM, Manjunath Kudlur <keveman at gmail.com> wrote: > I am seeing the following assertion in leak detector. > > /llvm/lib/VMCore/LeakDetector.cpp:43: > void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = > void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' > failed. > > I am

Hi Bill, I am using the following version of BuildMI : MachineInstrBuilder BuildMI(MachineFunction &MF, const TargetInstrDesc &TID, unsigned DestReg) I do the following : void createInstrs(std::vector<MachineInstr *>& ilist) { Machine Instr *mi; mi = BuildMI(MF, someTID, somereg);

On Wed, Jun 3, 2009 at 12:46 PM, Manjunath Kudlur<keveman at gmail.com> wrote: > Hello, > > I am writing a MachineFunction pass that converts vector instructions > to a sequence of scalar instructions. Why? That really isn't the level you want to be doing that sort of thing normally. Usually, legalization turns illegal vector operations into legal scalar operations. -Eli

Hi Salomon, please don't forget to reply to the list too (I've CC'd the list). > I don't think my code is doing anything worng... No, it looks fine to me, and the interpreter certainly supports this. That suggests that the value of %str is not being transmitted to the function right. If it is getting the wrong pointer value, that would explain why it barfs. Ciao, Duncan.

[I assume you meant to send this to the list as well, not just me.] Begin forwarded message: Date: Wed, 3 Nov 2010 14:43:54 +0000 From: Salomon Brys <salomon.brys at gmail.com> To: Török Edwin <edwintorok at gmail.com> Subject: Re: [LLVMdev] Forcing the Interpreter segfaults I have build LLVM in debug mode. Here are the informations of the segfault : memcpy() at 0x7ffff6f6581e

Dan, Thanks a lot. Using a modifier in the assembly string works for this case. I am trying to solve a related problem. I am trying to print out a set of "mov" ops for the vector_shuffle node. Since the source of the "mov" is from one of the sources to vector_shuffle, depending on the mask, I am not sure what assembly string to emit. For example, if I have d <-

Hello, I am trying to create a machine instruction for "extractelement". I want to translate r <- extractelement v, 0 to mov r, v.x I was looking at the dag I can use and I found vector_extract. The inputs for this SDnode are a register and a iPtr constant. With that, I need to create 4 separate def's to extract element 0, 1, 2, and 3 and translate to v.x, v.y, v.z, and v.w. I

I run large piece of code in JIT and it runs only marginallty faster with optimization levels 1,2,3. I think differences are within the margin or error. level user time 0 17339ms 1 16913ms 2 16891ms 3 16898ms Level is set with builder->setOptLevel(olev); Compilation time is excluded by taking the only top-level function address before the run

I want to add a set of "properties" to each instruction in my instruction set, and want to be able to query that in my machine-specific optimizations. My Insts.td file looks as follows : class InstProperty; def propX : InstProperty; def propY : InstProperty; def propZ : InstProperty; class myInst<..., list<InstProperty> props> : Instruction { ... ...

Hi, Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule);

Manjunath, I had a very similar problem and I solved it using a custom vector shuffle and addition instead of mov. For example, Vector_shuffle s1, s2, <0,3> is mapped to a custom instruction where I transform the swizzle to a 32bit integer mask and an inverted mask. So I have dst, src0, src1, imm1, imm2 And I have my asm look similar to: Add dst, src0.imm1, src1.imm2 and then in the asm

I'm having a problem with MCJIT (in LLVM 3.3 and 3.4), in which it's not resolving symbol mangling in a precompiled bitcode in the same way as old JIT. It's possible that it's just my misunderstanding. Maybe somebody can spot my problem, or identify it as an MCJIT bug. Here's my situation, in a nutshell: * I am assembling IR and JITing in my app. The IR may potentially make

Hi, I'm seeing rather high memory usage from LLVM and I'd like to track down what I'm doing to cause it. My application is a simple web application server that compiles web pages with embedded script to bitcode and compiles them with the JIT on demand. I've taken tools/lli.cpp as a starting point and extended it to load additional modules. However, if I load successive pages and

Thanks for replying so fast. This UnsafeFPMath trick in fact solves "pxor adds" case, but the resulting code is still not as good as I expected from LLVM. For example expressions like "1+x+1+x+1+x+1+x" (basically adding a lot of constants and variables) are complied to a long series off <add>s both in IR and assembly code. Both GCC and MSVC generates C1*x +C2 (mov +

One way to do this is to handle this in the AsmPrinter, with operand modifiers. For example, on x86 there are instructions with ${dst:call} in their asm string. The "call" part is interpreted as an operand modifier. The assembly printer looks for the "call" modifier on MachineOperand::MO_Immediate operands (in X86ATTAsmPrinter::printOperand), which lets it perform custom

I get a segfault with this code when setting the data layout: int main(int argc, char** argv) { llvm::InitializeNativeTarget(); llvm::LLVMContext TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName());

On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: > Hi, > > Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? > > I tried to play with TargetOptions without any success… > > Here is the kind of code we use to

On 08/02/13 15:42, David Tweed wrote: > | For ARM, you will need to use the MCJIT ExecutionEngine as the legacy > | one is broken for ARM. (call EngineBuilder::setUseMCJIT()). > > Also remember to include the correct MCJIT headers not the JIT one's: > calling setUseMCJIT() with the old JIT headers are the only ones being > included just constructs an old JIT, it doesn't