search for: operands

Hi ES, From what I understand instruction parsing is divided into two parts: - Parsing an operand list (XXXAsmParser::ParseInstruction) - Turning the operand list into an actual instruction (XXXAsmParser::MatchAndEmitInstruction) The second part does the validation (e.g. how many operands, what kind, etc) while the first part only does the parsing. That's why I think in the first part you have to handle all possible operand combinations (i.e. parse the first operand, and keep parsing operands as long as you see spaces). LLVM will reject instructions with too many operands (a...

Hi, I think I've found a bug 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,...

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote: > Hi, > > I think I've found a bug 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, >...

...ng debug mode). However, > even while those instructions may no longer be rejected, the code that is > generated doesn't seem to be correct either. It’s a bit outside the scope of what the matcher really wants to deal with, yes. > One underlying cause of the problem is the way tied operands are handled: > If operand I is tied to J (where I < J), then the actual operand is emitted > when at location I, and when at location J a copy of what is already at > location I is emitted. To ensure this can always be done, > buildInstructionOperandReference "canonicalizes&quo...

...;Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, March 13, 2014 9:46:22 AM > Subject: Re: [LLVMdev] Be Careful with Positionally-Encoded Operands (AArch64, Mips, AMDGPU, etc.) > > On Thu, Mar 13, 2014 at 03:21:47AM -0500, Hal Finkel wrote: > > Hello, > > > > Some of the backends seem to be combining positional and named > > operands when defining some instructions such that some of the > > positional ope...

...Definition Our motivation behind this is to track the state required for deoptimization (described briefly later) through the LLVM pipeline as a first-class IR citizen. We want to do this is a way that is generally useful. An "operand bundle" is a set of SSA values (called "bundle operands") tagged with a string (called the "bundle tag"). One or more of such bundles may be attached to a call or an invoke. The intended use of these values is to support "frame introspection"-like functionality for managed languages. # Abstract Syntax The syntax of a call i...

Hi all. I'm looking for some way to do code analysis with LLVM. Can someone please give me a hint, if it is possible to query an MCInst for what are input operands and what are output operands? Small example. Consider we have an instruction: str r1, [sp, #8] Being mapped into MCInst instance it has the following operands: <MCOperand Reg:61> <-- maps to reg r1 <MCOperand Reg:105> <-- maps to reg sp <MCOperand Imm:8>...

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the left as we use AT&T syntax by default. It will probably conflict with your u...

...; > deoptimization (described briefly later) through the LLVM pipeline > > as > > > a first-class IR citizen. We want to do this is a way that is > > > generally useful. > > > An "operand bundle" is a set of SSA values (called "bundle > > operands") > > > tagged with a string (called the "bundle tag"). One or more of such > > > bundles may be attached to a call or an invoke. The intended use of > > > these values is to support "frame introspection"-like functionality > > > for...

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those

...ddle of the declaration of // your subclasses implementation of MCTargetAsmParser. unsigned ComputeAvailableFeatures(uint64_t FeatureBits) const; void convertToMCInst(unsigned Kind, MCInst &Inst, unsigned Opcode, const SmallVectorImpl<MCParsedAsmOperand*> &Operands); void convertToMapAndConstraints(unsigned Kind, const SmallVectorImpl<MCParsedAsmOperand*> &Operands); bool mnemonicIsValid(StringRef Mnemonic); unsigned MatchInstructionImpl( const SmallVectorImpl<MCParsedAsmOperand*> &am...

Hello, Some of the backends seem to be combining positional and named operands when defining some instructions such that some of the positional operands overlap with some of the named operands. I suspect this is not intentional; here's an example: AArch64 has the following instruction definition: SMULHxxx { field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0...

Hi all, in most of the architectures, assembly operands are comma-separated. I would like to parse an assembly code that is space-separated and I am having a bit of problem. In *ParseInstruction* function, I don't know what is the easiest way to figure out how many operands a mnemonic expected to have. In comma-separated assembly code, it just consu...

...completely different. I’m assuming you mean converters for > the rest. If that’s not the case, please let me know and I’ll back > up and re-think. Right, custom converters (i.e. AsmMatchConverter). Sorry for the confusion with terminology ... > There are two core issues. First, the tied operands are an artifact > of the way we do instruction selection for the compiler. They’re how > we represent read-modify-write operands, basically. The assembler > shouldn’t have to know or care about them at all. Specifically, they > shouldn’t even be represented at all as an MCOperand. Rathe...

On Apr 18, 2007, at 2:07 PM, Evan Cheng wrote: > > On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > >> I noticed that the TableGen code emitter generator assumes that >> the instruction fields are declared in the instruction format in >> the same order that operands are defined. This seems like a bad >> dependence to me, and that TableGen should match the name of field >> declared in the instruction with the name of the operand in order >> to determine which operand of the MI to use >> . > > Yes, instruction OperandList corr...

If I have an instruction which has many register and immediate operands, what's the difference between these two implementations to define the instruction in TableGen *.td file? (1) Similar to what has been done to complex X86 addressing mode. A single 32-bit immediate (i32) encodes how to add many MachineOperands to the MachineInstr object (With the help of func...

...>> 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. > >> The description should only have 4 operands + v...

I noticed that the TableGen code emitter generator assumes that the instruction fields are declared in the instruction format in the same order that operands are defined. This seems like a bad dependence to me, and that TableGen should match the name of field declared in the instruction with the name of the operand in order to determine which operand of the MI to use . See CodeEmitterGen.cpp:170 and neighborhood. Unfortunately there are naming di...

...;(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts, variable_ops), IndexModeNone, LdStMulFrm, IIC_iLoadm, "ldm${addr:submode}${p}\t$addr, $dsts", "", []>; Tablegen produces an instruction description with 5 input operands: 2 for $addr, 2 for $p, and 1 for $dsts. But $dsts and the following variable_ops are all outputs! The description should only have 4 operands + variable_ops. How can you specify a named, variable list of output operands? Perhaps this could be made to work: def reglist : Operand<i32> {...

As part of adding `"deopt"` operand bundles, we're aiming to change RewriteStatepointsForGC (called RS4GC henceforth) from rewriting existing `gc.statepoint` calls to transforming normal LLVM calls and invokes into `gc.statepoint` calls and invokes (i.e. to do PlaceSafepoints + RS4GC in one step). This will make `gc.statepoint` an artifact of the gc lowering strategy that only