search for: targetinstrdesc

...:$addr, pred:$p, > reglist:$dsts, variable_ops), > IndexModeNone, LdStMulFrm, IIC_iLoadm, > "ldm${addr:submode}${p}\t$addr, $dsts", "", []>; > > Tablegen produces an instruction description Ok, you mean TargetInstrDesc, right? > with 5 input operands: 2 for $addr, 2 for $p, and 1 for $dsts. But $dsts and the following variable_ops are all outputs! Right, variable_ops means that it takes a variable number of operands, not that an operand has a variable number of registers. > The description should only ha...

hi, when using the execution engine (no matter, if JIT or Interpreter) i get the following assertion as soon as i use boost::shared_ptr: /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' failed. how can i find out which instruction is executed at this point or in which function we are currently? i also attached a very small example, which triggers the assertion when run with lli. thanks a lot in ad...

Hi, After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: // A list of registers separated by comma. Used by load/store multiple. def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts,

...ding these in your calculations you will probably have some errors. > My apologies for not mentioning this earlier. > > You can find the set of implicit uses and defs by querying the > TargetInstDesc object for each MachineInstr (call MachineInstr::getDesc() to > get it, and then the TargetInstrDesc::getImplicitUses() and > TargetInstrDesc::getImplicitDefs() methods to find the regs used/definied by > this instr). > Oops. Seems we copy implicit operands like this into MachineOperands on the instruction before register allocation. Disregard the above advice - you do not need to check...

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); ilist.push_back(mi); mi = BuildMI(MF, someotherTID, someotherreg); ilist.push_ba...

...failure when using thread-local variables and the fast emitter. It only happens with the JIT, the fast emiiter and thread-locals. (The IR passes the verifier) Here's the failure: X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "psuedo instructions should be removed before code emission"' failed. There is a problem with submitting a bug-report, however. Since llc has no trouble with thread-locals, I cannot actually generate the assertion failure, without my compiler-generator. I...

...reglist:$dsts, variable_ops), >> IndexModeNone, LdStMulFrm, IIC_iLoadm, >> "ldm${addr:submode}${p}\t$addr, $dsts", "", []>; >> >> Tablegen produces an instruction description > > Ok, you mean TargetInstrDesc, right? Yes. >> with 5 input operands: 2 for $addr, 2 for $p, and 1 for $dsts. But $dsts and the following variable_ops are all outputs! > > Right, variable_ops means that it takes a variable number of operands, not that an operand has a variable number of registers. > >> T...

...ds. If you are not including these in your calculations you will probably have some errors. My apologies for not mentioning this earlier. You can find the set of implicit uses and defs by querying the TargetInstDesc object for each MachineInstr (call MachineInstr::getDesc() to get it, and then the TargetInstrDesc::getImplicitUses() and TargetInstrDesc::getImplicitDefs() methods to find the regs used/definied by this instr). 2) How are you making sure that interfering virtregs never receive the same physreg? If you're using the LiveIntervals analysis (and the LiveInterval::overlaps(LiveInterval &) t...

...ter. >> It only happens with the JIT, the fast emiiter and thread-locals. >> (The IR passes the verifier) >> >> Here's the failure: >> >> X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const >> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && >> "psuedo instructions should be removed before code emission"' failed. >> >> There is a problem with submitting a bug-report, however. >> Since llc has no trouble with thread-locals, I cannot actually >> generate >> th...

You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equivalent inform...

...the execution engine (no matter, if JIT or Interpreter) i get the > following assertion as soon as i use boost::shared_ptr: > > /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: > void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const > llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' > failed. > > how can i find out which instruction is executed at this point or in which > function we are currently? > > i also attached a very small example, which triggers the assertion when run &g...

> You have to create one! Take a look at PPCHazardRecognizers.cpp > and SPUHazardRecognizers.cpp for examples. > If you can, contribute it back! :) There is also generic hazard recognizer which works on top of instruction itineraries. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...variables and the fast emitter. > It only happens with the JIT, the fast emiiter and thread-locals. > (The IR passes the verifier) > > Here's the failure: > > X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const > llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && > "psuedo instructions should be removed before code emission"' failed. > > There is a problem with submitting a bug-report, however. > Since llc has no trouble with thread-locals, I cannot actually > generate > the assertion failure, wit...

How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596

...o matter, if JIT or Interpreter) i get > > the following assertion as soon as i use boost::shared_ptr: > > > > /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: > > void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const > > llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline > > asm!\n"' failed. > > > > how can i find out which instruction is executed at this point or in > > which function we are currently? > > > > i also attached a very small example, which trigge...

...odule()->getFunction("powf"); func = CloneFunction(originalFunc, val); currentModule()->getFunctionList().push_back(func); unfortunately after this we get an assert: vp-tris: /home/zack/projects/general/llvm/lib/Target/X86/X86CodeEmitter.cpp:412: unsigned int sizeOfImm(const llvm::TargetInstrDesc*): Assertion `0 && "Immediate size not set!"' failed. which I'm a little confused about. Any idea what might be causing this and how to fix it? z

...JIT, the fast emiiter and thread-locals. >>> (The IR passes the verifier) >>> >>> Here's the failure: >>> >>> X86CodeEmitter.cpp:516: >>> void<unnamed>::Emitter::emitInstruction(const >>> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && >>> "psuedo instructions should be removed before code emission"' >>> failed. >>> >>> There is a problem with submitting a bug-report, however. >>> Since llc has no trouble with thread-locals, I cannot actually...

...gned RegNo) const; > - bool isX86_64ExtendedReg(const MachineOperand &MO); > - unsigned determineREX(const MachineInstr &MI); > > bool gvNeedsLazyPtr(const GlobalValue *GV); > }; > @@ -405,139 +403,6 @@ > } > } > > -static unsigned sizeOfImm(const TargetInstrDesc *Desc) { > - switch (Desc->TSFlags & X86II::ImmMask) { > - case X86II::Imm8: return 1; > - case X86II::Imm16: return 2; > - case X86II::Imm32: return 4; > - case X86II::Imm64: return 8; > - default: assert(0 && "Immediate size not set!"); > -...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

...perand information to be less target-dependent and to > make at least AliasAnalysis::pointsToConstantMemory queries. OK, I will have a look. I assume the reference to M_REMATERIALIZABLE in the comment for it should really be TID::Rematerializable? I also noticed that the documentation for TargetInstrDesc::isRematerializable() says "This flag is deprecated, please don't use it anymore" -- could you explain what replaces it? Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463