search for: numdef

...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 HasPhysRegOuts = NumResults > NumDefs && II.getImplicitDefs()!=nullptr; Where NumResults is the number of outputs in the MachineSDNode and NumDefs comes from the MCInstrDesc and ultimately the TableGen definition of the instruction. I do not know why this assumption is made or what code depends on it, but it is over 12 years...

...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 HasPhysRegOuts = NumResults > NumDefs && > II.getImplicitDefs()!=nullptr; > > Where NumResults is the number of outputs in the MachineSDNode and NumDefs > comes from the MCInstrDesc and ultimately the TableGen definition of the > instruction. I do not know why this assumption is made or what code depends > on...

...eSDNode 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 HasPhysRegOuts = NumResults > NumDefs && >> II.getImplicitDefs()!=nullptr; >> >> Where NumResults is the number of outputs in the MachineSDNode and >> NumDefs comes from the MCInstrDesc and ultimately the TableGen definition >> of the instruction. I do not know why this assumption is made or what...

...al. 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 better than trying to maintain a duplicate set of opcodes though. I’m still t...

...han 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 HasPhysRegOuts = NumResults > NumDefs && >>> II.getImplicitDefs()!=nullptr; >>> >>> Where NumResults is the number of outputs in the MachineSDNode and >>> NumDefs comes from the MCInstrDesc and ultimately the TableGen definition >>> of the instruction. I do not know why this assumpt...

Hello. Hal, the problem I have is that it doesn't advance at the next available instruction - it always gets the same store. This might be because I did not specify in a file like [Target]Schedule.td the functional units, processor and instruction itineraries. Regarding the Stalls argument to my method [Target]DispatchGroupSBHazardRecognizer::getHazardType() I always get the

...most part it's just read into CodeGenInstruction::ImplicitDefs and then GlobalISel gathers and adds them all at the end. I think I do see the code Gabriel is referring to though. GetNumNodeResults() has: if (InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other) ++NumDefsToAdd; and ultimately this VT gets into Types via UpdateNodeType(). I have no idea why this code does this as I don't really see why the VT matters to how you treat an implicit def. This code dates back to 2010 (r99726) and that commit called it 'funky logic' so it's unlikely that...

...f MachineInstr > objects. Essentially, MCInstrDesc is not meant to be used to describe MCInst > objects. To be more specific, MCInstrDesc objects are automatically generated > via tablegen from the instruction set description in the target .td files. For > example, field `MCInstrDesc::NumDefs' is always equal to the cardinality of the > `(outs)` set from the tablegen instruction definition. > > By construction, register definitions always appear at the beginning of the > MachineOperands list in MachineInstr. Basically, the (outs) are the first > operands of a Machin...

...erties and operands of MachineInstr objects. Essentially, MCInstrDesc is not meant to be used to describe MCInst objects. To be more specific, MCInstrDesc objects are automatically generated via tablegen from the instruction set description in the target .td files. For example, field `MCInstrDesc::NumDefs' is always equal to the cardinality of the `(outs)` set from the tablegen instruction definition. By construction, register definitions always appear at the beginning of the MachineOperands list in MachineInstr. Basically, the (outs) are the first operands of a MachineInstr, and the (ins) wil...

...; objects. Essentially, MCInstrDesc is not meant to be used to describe > MCInst > objects.  To be more specific, MCInstrDesc objects are automatically > generated > via tablegen from the instruction set description in the target .td > files.  For > example, field `MCInstrDesc::NumDefs' is always equal to the > cardinality of the > `(outs)` set from the tablegen instruction definition. > > By construction, register definitions always appear at the beginning > of the > MachineOperands list in MachineInstr. Basically, the (outs) are the first > operands...

...> objects. Essentially, MCInstrDesc is not meant to be used to describe > MCInst > objects. To be more specific, MCInstrDesc objects are automatically > generated > via tablegen from the instruction set description in the target .td > files. For > example, field `MCInstrDesc::NumDefs' is always equal to the cardinality > of the > `(outs)` set from the tablegen instruction definition. > > By construction, register definitions always appear at the beginning of the > MachineOperands list in MachineInstr. Basically, the (outs) are the first > operands of a Ma...

...> objects. Essentially, MCInstrDesc is not meant to be used to describe > MCInst > objects. To be more specific, MCInstrDesc objects are automatically > generated > via tablegen from the instruction set description in the target .td > files. For > example, field `MCInstrDesc::NumDefs' is always equal to the cardinality > of the > `(outs)` set from the tablegen instruction definition. > > By construction, register definitions always appear at the beginning of the > MachineOperands list in MachineInstr. Basically, the (outs) are the first > operands of a Ma...