search for: addoperand

...in this method. I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg, false, // isDef true)); // isImplicit As, can be seen, it is presumed that this operand is always the last operand, this is however not the case. It in fact becomes the...

...t on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. > > For the def-operand, with a subregindex, an implicit-use operand was added with this code: > > VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); > MI.addOperand(MachineOperand::CreateReg(VirtReg, > false, // isDef > true)); // isImplicit > > As, can be seen, it is presumed that this operand is always the last operand, this is however not the case. It...

Yes, I'm saying that the implicit-def operand that was added in this case ended up as #4, out of 6, when the operands list was reallocated in addOperand(). If addOperand was rewritten, I think it's best not to add my fix for ProcessUses(), as I wrote earlier. Jonas Subject: Re: [LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses() From: stoklund at 2pi.dk Date: Wed, 12 Oct 2011 09:14:52 -0700 CC: llvmdev at cs.uiuc.edu To: jnspaulsson...

...wine tname("my_label_name"); llvm::MCSymbol* mcs = Ctx.getOrCreateSymbol(tname); Str->EmitLabel(mcs); Or even something more complicated like setting up an MCInst and all it's operands: llvm::MCInst *llinst = new MCInst(); llinst->setOpcode(input_opcode); llinst->addOperand(llvm::MCOperand::createReg(input_reg0)); llinst->addOperand(llvm::MCOperand::createReg(input_reg1)); const llvm::Twine tname("label_name"); const llvm::MCSymbol* mcs = Ctx.getOrCreateSymbol(tname); const llvm::MCSymbolRefExpr *msre = llvm::MCSymbolRefExpr::create(mcs, Ctx); l...

...bout the particular object/value which caused the assertion. In a 'data oriented' system like llvm, this makes it really difficult to pinpoint which node is actually triggering the assertion. For example, in ScheduleDAGSDNodesEmit.cpp (lib/CodeGen/SelectionDAG/), in the ScheduleDAGSDNodes::AddOperand method, there is the following assert: assert(Op.getValueType() !=MVT::Other && Op.getValueType() != MVT::Flag && "Chain and flag operands should occur at end of operand list!"); In order to understand which operand was causing the failure, I need to dig quite a lot. Wh...

...at could be something other than a Reg: mem, global address, imm, etc... I want to replace a reg MachineOperand with this non-reg MachineOperand. I've tried a few different things, but it doesn't seem like there is some simple functionality to do this? "RemoveOperand" and "addOperand" does not work. There doesn't seem to be a valid "ChangeTo..." function for this. What's the best way to do this without tearing down the instructions and using BuildMI? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://list...

...Thumb1InstrInfo::Thumb1InstrInfo(const ARMSubtarget &STI) : ARMBaseInstrInfo(STI), RI(STI) { } /// getNoopForMachoTarget - Return the noop instruction to use for a noop. void Thumb1InstrInfo::getNoopForMachoTarget(MCInst &NopInst) const { NopInst.setOpcode(ARM::tMOVr); NopInst.addOperand(MCOperand::CreateReg(ARM::R8)); NopInst.addOperand(MCOperand::CreateReg(ARM::R8)); NopInst.addOperand(MCOperand::CreateImm(ARMCC::AL)); NopInst.addOperand(MCOperand::CreateReg(0)); } unsigned Thumb1InstrInfo::getUnindexedOpcode(unsigned Opc) const { return 0; } void Thumb1InstrI...

Is it possible to get a virtual register and then use that to create a real register? I've seen it done in unittests/CodeGen/MachineInstrTest.cpp like this: unsigned VirtualDef1 = -42; VD1VU->addOperand(*MF, MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true)); But when I do that in my code I get an assertion so I wasn't sure if it's legal or not. Thanks. ________________________________ From: David Greene <dag at cray.com> Sent: Wednesday, January 2, 2019 9...

...d attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const llvm::MachineOperand&): Assertion `(isImpReg || !OperandsComplete()) && "Trying to add an operand to a machine instr that is already done!"' failed. Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc12607_0/ghc12607_0.bc -o /tmp/ghc12607_0...

...fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign > ed int, std::less<llvm::SDNode*>, std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): Assertion `R > egMap->getRegClass(...

...Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 53702) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@ -6010,7 +6010,9 @@ for (int i=0; i <= lastAddrIndx; ++i) (*MIB).addOperand(*argOpers[i]); MIB.addReg(t2); - + assert(bInstr->hasOneMemOperand() && "Unexpected number of memoperand"); + (*MIB).addMemOperand(*F, *bInstr->memoperands_begin()); + MIB = BuildMI(newMBB, TII->get(X86::MOV32rr), destOper.getReg()); MIB.addReg(X86::EAX);...

...ct/value which caused the > assertion. In a 'data oriented' system like llvm, this makes it really > difficult to pinpoint which node is actually triggering the assertion. > > For example, in ScheduleDAGSDNodesEmit.cpp > (lib/CodeGen/SelectionDAG/), in the ScheduleDAGSDNodes::AddOperand > method, there is the following assert: The typical idiom we use for this are things like: Value::~Value() { #ifndef NDEBUG // Only in -g mode... // Check to make sure that there are no uses of this value that are still // around when the value is destroyed. If there are, then w...

...l i1 @i1_s = external global i1 define void @i1_ls() nounwind { %tmp = load i1* @i1_l store i1 %tmp, i1* @i1_s ret void } Instruction selection works correctly, but the scheduling step fails with "Register class of operand and regclass of use don't agree!" in ScheduleDAGSDNodes::AddOperand. The selected DAG contains: (LOAD32p_8z (LOAD32imm (tglobaladdr "i1_l"))) LOAD32imm produces a GR-class vreg, and LOAD32p_8z expects a P-class vreg, hence the error. But P is a subclass of GR, so if the vreg class were changed to P everything would work. The solution is not always...

...tc... > > > > I want to replace a reg MachineOperand with this non-reg MachineOperand. > > > > I've tried a few different things, but it doesn't seem like there is some > > simple functionality to do this? > > > > "RemoveOperand" and "addOperand" does not work. > > There doesn't seem to be a valid "ChangeTo..." function for this. > > > > > > What type of operand do you want to change it to? If there is no > "ChangeTo..." function for the new type, I think the best thing to do > wo...

...n the inference fails. We would get all kinds of weird attributes on our instructions without even noticing. Crazy! ;) Are there cases where code calls BuildMI().addReg() without knowing if it is adding a use or a def? That seems like it would be rare. We could add assertions inside MachineInstr::addOperand() to check the uses and defs against the MCInstrDesc. We do have code, though, that modifies an instruction in place before swizzling the descriptor. Such code could be fixed, I guess. /jakob

...empted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: > > llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const llvm::MachineOperand&): Assertion `(isImpReg || !OperandsComplete()) && "Trying to add an operand to a machine instr that is already done!"' failed. > Stack dump: > 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc12607_0/ghc12607_0.bc -o /tmp/ghc...

Fernando, The code there should be more or less functional, though it's not currently used by anything. Eventually it should probably be moved to a method on MachineBasicBlock. The API breakage you're seeing is because some methods moved around. Feel free to fix it. :-) --Owen On Jan 26, 2008, at 6:31 PM, Fernando Magno Quintao Pereira wrote: > > Hi LLVMers, > >

...to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: >> >> llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const llvm::MachineOperand&): Assertion `(isImpReg || !OperandsComplete())&& "Trying to add an operand to a machine instr that is already done!"' failed. >> Stack dump: >> 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc12607_0/ghc12607_0.bc -o...

Hi LLVMers, what is the status of breaking critical edges in machine functions? I just compiled the top of the LLVM tree, and I found llvm/CodeGen/BreakCriticalMachineEdge.h. But this file seems not to be up-to-date with the other classes in the top of the tree. For instance, it calls isTerminatorInstr on llvm::TargetInstrInfo, but this method is no longer there. If I want to break