search for: instremitter

Hi, I wonder if anyone has any comment on a patch like: diff --git a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp index 65ee3816f84..4780f6f0e59 100644 --- a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp +++ b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp @@ -243,18 +243,21 @@ void InstrEmitter::CreateVirtualRegisters(SDNode *Node,      if (!VRBase && !IsClon...

...with a diamond CFG by the scheduler. The high level ScheduleDAGSDNodes::EmitSchedule does this: for (unsigned i = 0, e = Sequence.size(); i != e; i++) { [...] Emitter.EmitNode(SU->getNode(), SU->OrigNode != SU, SU->isCloned, VRBaseMap); [...] } TheInstrEmitter::EmitMachineNode does this: if (II.usesCustomInsertionHook()) { // Insert this instruction into the basic block using a target // specific inserter which may returns a new basic block. bool AtEnd = InsertPos == MBB->end(); MachineBasicBlock *NewMBB = TLI->EmitInstrWithCusto...

...bit part registers. I have tried to find a simple way to constrain the register class of such copies (also at -O0), but this turned out to not be quite simple. Just selecting a pseudo instruction with a custom inserter does not seem to work since CopyToReg/CopyFromReg have special handlings in InstrEmitter. I then tried in SystemZDAGToDAG.cpp to select a CopyToReg to (CopyToReg COPY_TO_REGCLASS), which worked fine. But I could not get the same results with CopyFromReg. (COPY_TO_REGCLASS CopyFromReg) only resulted in a later COPY into GR32, but the COPY from the Access register was still first ma...

Hi, Assume I define registers R0...R15 and two register classes RegA and RegB. RegA contains R0 to R7 while RegB contains R0 to R15. Then I check the machine instruction, it seems that in some cases, the %vreg0 belongs to RegB; in other cases %vreg1 belongs to RegA_RegB. Can you tell me how TableGen decides which is which? At first, I guess &verg0 will be assigned by R8 to R15 only so that

...ay be of general interest. I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code that relies on the TII for that kind of thing -- for instance, InstrEmitter::EmitMachineNode() does this: bool HasPhysRegOuts = NumResults > NumDefs && II.getImplicitDefs()!=nullptr; where “NumDefs” comes from TII and “NumResults” comes from the node. Obviously we can fix that up as needed, but it seems like a weak point in the design. Perhaps it is still...

...s of Instructions in TableGen. So that won't work. The other approach is to have just one call instruction that has variadic outputs as well as inputs. This is the approach I am pursuing now, and I have it working through the lowering to MachineSDNodes, but the approach is breaking down in the InstrEmitter because it is trying to use physical registers. WebAssembly is a stack machine, so all instructions including calls push their results onto the value stack as opposed to placing them in registers. The value stack is not in memory and not addressable, so it is not the same as the normal stack of ca...

...leGen. So that won't work. > > The other approach is to have just one call instruction that has variadic > outputs as well as inputs. This is the approach I am pursuing now, and I > have it working through the lowering to MachineSDNodes, but the approach is > breaking down in the InstrEmitter because it is trying to use physical > registers. > > WebAssembly is a stack machine, so all instructions including calls push > their results onto the value stack as opposed to placing them in registers. > The value stack is not in memory and not addressable, so it is not the same &...

...in the lower part of the 64bit register pair and write 0 to higher part. Finally, these parts are glued together using ISD::BUILD_PAIR. However, when I try to insert such nodes into the DAG within TriCoreTargetLowering, I run into an assertion: llc: /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, llvm::DenseMap<llvm::SDValue, unsigned int>&): Assertion `NumMIOperands >= II.getNumOperands() && NumMIOperands <= II.getNumOperands()+II.getNumImplicitDefs() && "#operands for dag node...

...t register pair and write 0 to higher part. > Finally, these parts are glued together using ISD::BUILD_PAIR. > However, when I try to insert such nodes into the DAG within > TriCoreTargetLowering, I run into an assertion: > > llc: > /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: > void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, > llvm::DenseMap<llvm::SDValue, unsigned int>&): Assertion > `NumMIOperands >= II.getNumOperands() && NumMIOperands <= > II.getNumOperands()+II.getNumImplicitDefs() && "#o...

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

...Unconditionally(llvm::Value*, llvm::Instruction*, unsigned int, llvm::TargetData const*)in libLLVMAnalysis.a(Loads.cpp.o) llvm::DAGTypeLegalizer::SplitVecRes_INSERT_VECTOR_ELT(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&)in libLLVMSelectionDAG.a(LegalizeVectorTypes.cpp.o) llvm::InstrEmitter::AddOperand(llvm::MachineInstr*, llvm::SDValue, unsigned int, llvm::TargetInstrDesc const*, llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo<llvm::SDValue>, llvm::DenseMapInfo<unsigned int> >&, bool, bool, bool)in libLLVMSelectionDAG.a(InstrEmitter.cpp.o) l...

...x30eb000, TID=@0x803a9f840, DL={LineCol = 0, ScopeIdx = 0}, NoImp=false) at /tmp/llvm-svn/llvm/lib/CodeGen/MachineFunction.cpp:153 #2 0x00000008028ea302 in llvm::BuildMI (MF=@0x30eb000, DL={LineCol = 0, ScopeIdx = 0}, TID=@0x803a9f840) at MachineInstrBuilder.h:147 #3 0x0000000803164513 in llvm::InstrEmitter::EmitMachineNode (this=0x7fffffff7f80, Node=0x4b6c510, IsClone=false, IsCloned=false, VRBaseMap=@0x7fffffff8050) at /tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:671 #4 0x00000008031f6bdf in llvm::InstrEmitter::EmitNode (this=0x7fffffff7f80, Node=0x4b6c510, IsClone=false, IsClon...

...nows where > the value is going to end up and that’s only achievable in a physical > register. > > Cheers, > -Quentin > > On Nov 18, 2019, at 6:21 PM, Thomas Lively via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I need to figure out why InstrEmitter::EmitMachineNode assumes that when > the number of outputs of a MachineSDNode is greater than the number of defs > in the corresponding MCInstrDesc, the outputs in the difference will be > placed into physical registers as opposed to virtual registers. > > The specific line in questi...

...>> I have not tried 3.5, it's a significant amount of work to port from one >> version to the next though, I did not personally do the 3.4 to 3.6 porting. >> I agree though, it was very strange that it suddenly just changed behavior. >> >> It looks like to me that InstrEmitter.cpp:getVR is the one assigning the >> virtual register no? >> >> >> No, IIRC getVR only create the virtual register for implicit defs. Which >> is not your case, right? >> >> >> Though this code in CreateVirtualRegisters: >> >> const Targe...

...te 0 to higher part. >> Finally, these parts are glued together using ISD::BUILD_PAIR. >> However, when I try to insert such nodes into the DAG within >> TriCoreTargetLowering, I run into an assertion: >> >> llc: >> /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704: >> void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, >> llvm::DenseMap<llvm::SDValue, unsigned int>&): Assertion >> `NumMIOperands >= II.getNumOperands() && NumMIOperands <= >> II.getNumOperands()+II.getNumImplicitDefs() &am...

I have not tried 3.5, it's a significant amount of work to port from one version to the next though, I did not personally do the 3.4 to 3.6 porting. I agree though, it was very strange that it suddenly just changed behavior. It looks like to me that InstrEmitter.cpp:getVR is the one assigning the virtual register no? Though this code in CreateVirtualRegisters: const TargetRegisterClass *RC = TRI->getAllocatableClass(TII->getRegClass(II, i, TRI, *MF)); That returns GPRBaseRegs for RC, but it then decides to constrain it based on type: if (i...

....com> wrote: > > I have not tried 3.5, it's a significant amount of work to port from one > version to the next though, I did not personally do the 3.4 to 3.6 porting. > I agree though, it was very strange that it suddenly just changed behavior. > > It looks like to me that InstrEmitter.cpp:getVR is the one assigning the > virtual register no? > > > No, IIRC getVR only create the virtual register for implicit defs. Which > is not your case, right? > > > Though this code in CreateVirtualRegisters: > > const TargetRegisterClass *RC = > TRI->...

...SD opcodes for > each desired set of call-clobbered registers. The problem is the large number of call-like instructions. We would need copies of CALL*, TCRETURN*, and TAILJMP* for each calling convention. I was hoping we could avoid that, and even get rid of the WINCALL instructions. What if InstrEmitter::EmitMachineNode called a target hook to add call-clobbered registers when II.isCall()? We would need some way of communicating the calling convention to the target hook. An immediate operand could work. /jakob

...x100156746c0, 0x10015671b80 [ORD=49] [ID=2] SU(1): 0x10015671d80: ch = CopyToReg 0x100156463c8, 0x10015677c70, 0x100156749c0 [ORD=49] [ID=1] SU(0): 0x100156762d0: ch = TokenFactor 0x10015678c80, 0x10015679180, 0x10015671d80 [ORD=50] [ID=0] which then asserts: llvm-trunk/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:292: unsigned int llvm::InstrEmitter::getVR(llvm::SDValue, llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo<llvm::SDValue> >&): Assertion `I != VRBaseMap.end() && "Node emitted out of order - late"' failed. What's gone wrong here? Is the...

Hi all, I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers. The specific line in question is: bool HasPhysR...