search for: mcinstrdesc

...other instructions writing to the program counter) and to differentiate between register definitions and uses to track all instructions the branch depends on. This works well for most cases, except if there are Thumb pop instructions involved. Pop has a variable number of output registers, so MCInstrDesc::getNumDefs returns zero and, as far as I can see, in the tablegen files 'variable_ops' is always in the 'ins' list and MCInstrDesc only provides isVariadic(); My current workaround is to assume that all variadic arguments of instructions that have zero register definitions but...

Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > Hi Christoph, > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > defs. Since variadic instructions will always require some kind of special > handling, it doesn't seem worthwhile to make the model more detailed. I don't see what makes them so different from other instructions. MCInstrDesc provide...

Hi, I wonder if it is okay to add an operand that is not part of MCInstrDesc to an MI after isel? There are things going on like instruction combining, rematerialization etc, which may call MI with TI->get(opcode). If an MI would get replaced with a new instance of itself in this way, any previously added operands would get lost, as they are not part of the MCInstrD...

On Sep 24, 2012, at 6:39 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Is it possible to extend LLVM to check if 'variable_ops' is in 'ins' and/or > 'outs' in tablegen, so that MCInstrDesc could provide something like > hasVariadicDefs() and hasVariadicUses()? > > That way handling variadic instructions when disassembling would be much > easier and only instructions with variadic uses and defines would need > explicit special casing - if they even exist. Hi Christ...

...libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment - i.e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and OpInfo that need to be relocated. This can be fixed of course by having target-global arrays for those structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only storing offsets into those global arrays in MCInstrDesc...

...and to a machine instr that is already done!" Any comments? Thanks, Christoph Grenz Am Donnerstag, 27. September 2012, 01:42:04 schrieb Christoph Grenz: > Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > > Hi Christoph, > > > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > > defs. Since variadic instructions will always require some kind of special > > handling, it doesn't seem worthwhile to make the model more detailed. > > I don't see what makes them so different from other instructions....

Hello LLVM, I'd like to check TSFlags in my AsmBackend code. However AsmBackend objects don't have a reference to MCInstrInfo, which is the only way I've seen to reach TSFlags. A quickie grep shows that none of the existing targets check TSFlags in their AsmBackends. Is there any reason I shouldn't check TSFlags in AsmBackend? If not, what's the best way to go about it?

...nt >> - i.e. data that needs to be touched by the dynamic linker even though it's >> ultimately read-only, and data that cannot be shared between multiple >> processes using LLVM. >> >> It turns out that a solid ~1.3MB of that data is in the tablegen'd >> MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and >> OpInfo that need to be relocated. >> >> This can be fixed of course by having target-global arrays for those >> structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only >> storing offset...

Dear all, I am trying to write an AsmParser and a CodeEmitter for simple ADD instruction. Here is what I have in the TestGenInstrInfo.td: *extern const MCInstrDesc TestInsts[] = {...{ 23, 3, 1, 0, 0, 0, 0x0ULL, nullptr, nullptr, OperandInfo13, 0, nullptr }, // Inst #23 = ADD8_rr...}* I parse the instruction successfully but I am not sure what I did wrong that the Size (as you can see in the line above is Zero for this instruction. (In EncodeInstruction, Des...

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 HasPhysRegOuts = NumResults > NumDefs && II.getImplicitDefs()!=nullptr; Where NumResults is the number of outputs in the MachineSDNode and N...

On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote: > I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. Once you move beyond the fixed operands, it can't be determined automatically if the added register should be a use or a def. But I think it would be convenient to add addUse() and addDef() methods to MachineInstrBuilder, instead of requiring the tedious addReg(...,...

...known to be pushed onto the value stack just like any other defs. Slots on the value stack are represented by virtual registers until stackification, so for WebAssembly we do need the implicit defs to be stored in virtual registers. I guess the best thing to do for now would be to add a bit to the MCInstrDesc carrying this information. Thomas On Mon, Nov 18, 2019 at 6:53 PM Quentin Colombet <qcolombet at apple.com> wrote: > Hi Thomas, > > The reason is simply because an implicit def of a virtual register doesn’t > make sense in theory. > > The rationale is let say that an inst...

...en <stoklund at 2pi.dk> wrote: > >> >> On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >>> I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. >> >> Once you move beyond the fixed operands, it can't be determined automatically if the added register should be a use or a def. > > Yes, very true. It seems the builder should use the information for the fixed operands, though? Or at least perh...

..., Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Feb 20, 2013, at 11:44 AM, Jim Grosbach <grosbach at apple.com> wrote: > >> I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. > > Once you move beyond the fixed operands, it can't be determined automatically if the added register should be a use or a def. Yes, very true. It seems the builder should use the information for the fixed operands, though? Or at least perhaps the machine ve...

...;AArch64GenRegisterInfo.inc" #define GET_INSTRINFO_ENUM #include "AArch64GenInstrInfo.inc" #define GET_SUBTARGETINFO_ENUM #include "AArch64GenSubtargetInfo.inc" #include "llvm/MC/MCSchedule.h" #include "llvm/MC/MCRegisterInfo.h" #include "llvm/MC/MCInstrDesc.h" #include "llvm/MC/MCInstrInfo.h" #include "llvm/MC/SubtargetFeature.h" #include "llvm/MC/MCSubtargetInfo.h" #define GET_INSTRINFO_MC_DESC #include "AArch64GenInstrInfo.inc" #define GET_SUBTARGETINFO_MC_DESC #include "AArch64GenSubtargetInfo.inc...

...My rough understanding of the problem is that, while attempting to pick a node to schedule, we're running out of candidates (in ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to copy a node, and in the process, we call getPhysicalRegisterVT. This function asserts that the MCInstrDesc associated with the node will have ImplicitDefs, but in our case, it does not. In short: does this seem to be a problem of missing information in the MCInstrDesc, or should we not have arrived at that assert in the first place? Thanks, - Elliot -------------- next part -------------- An HTML att...

...vm/tools/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:87 - "const bool can_branch = mc_disasm_ptr->CanBranch(inst);"), while trying to set the next breakpoint. On this case, the instruction is the "bne cr7,0x2000092c", which is a branch, but at llvm/lib/MC/MCInstrDesc.cpp:35 - "if (isBranch() || isCall() || isReturn() || isIndirectBranch())" it returns false, making lldb do not set the correct breakpoint, so the execution does not stop at next line, which should be the "step over" behavior. The variable "Flags" for the disassembled...

...hould know from the instruction definition. Seems like it should do that. Why would you want it to not do that? Reed On 02/18/2013 01:22 PM, Jim Grosbach wrote: > Hi Reed, > > The .td file "Defs = …" should be sufficient. The implicit uses and implicit defs are part of the MCInstrDesc data structure, which is shared by all instances of a given instruction. > > -Jim > > On Feb 17, 2013, at 2:22 PM, reed kotler <rkotler at mips.com> wrote: > >> If I put in my tablegen td file that a certain instruction implicitly sets a register, do I need to also do the...

...onto the > value stack just like any other defs. Slots on the value stack are > represented by virtual registers until stackification, so for WebAssembly > we do need the implicit defs to be stored in virtual registers. I guess the > best thing to do for now would be to add a bit to the MCInstrDesc carrying > this information. > > Thomas > > On Mon, Nov 18, 2019 at 6:53 PM Quentin Colombet <qcolombet at apple.com> > wrote: > >> Hi Thomas, >> >> The reason is simply because an implicit def of a virtual register >> doesn’t make sense in theory....

...ng of the problem is that, while attempting to pick > a node to schedule, we're running out of candidates (in > ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to > copy a node, and in the process, we call getPhysicalRegisterVT. This > function asserts that the MCInstrDesc associated with the node will have > ImplicitDefs, but in our case, it does not. > > In short: does this seem to be a problem of missing information in the > MCInstrDesc, or should we not have arrived at that assert in the first > place? > > Thanks, > > - Elliot > >...