search for: operand's

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 y...

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, >...

...rote: > > Jakob, > > this is another TableGen patch related to handling pre-inc instruction > which I need as prerequisite for the PowerPC asm parser. > > The problem this patch attempts to fix is the handling of register tie > constraints in AsmMatcherEmitter, where one operand is tied to a > sub-operand of another operand. The typical scenario for this to happen is > the tie between the "write-back" register of a pre-inc instruction, and the > base register sub-operand of the memory address operand of that > instruction. > > Now from reading...

...;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 op...

We'd like to propose a scheme to attach "operand bundles" to call and invoke instructions. This is based on the offline discussion mentioned in http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/088748.html. # Motivation & Definition Our motivation behind this is to track the state required for deoptimization (described briefly late...

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...

...crosoft.com>, rudi at dropbox.com, "Pat Gavlin" > <pagavlin at microsoft.com>, "Joseph Tremoulet" <jotrem at microsoft.com>, > "Reid Kleckner" <rnk at google.com> > Sent: Monday, August 10, 2015 11:38:32 PM > Subject: Re: RFC: Add "operand bundles" to calls and invokes > On Sun, Aug 9, 2015 at 11:32 PM, Sanjoy Das < > sanjoy at playingwithpointers.com > wrote: > > We'd like to propose a scheme to attach "operand bundles" to call > > and > > > invoke instructions. This is based on...

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 to handle this instruction. Thanks, Manman On Jul 9, 2012, at 10:07 PM, Evan Cheng wrote: > > > On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > &gt...

...cluded into the middle 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<MCParsed...

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,...

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 cons...

...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. Rath...

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 cor...

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 fun...

...Olesen wrote: > >> Hi, >> >> After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: >> >> // A list of registers separated by comma. Used by load/store multiple. >> def reglist : Operand<i32> { >> let PrintMethod = "printRegisterList"; >> } >> >> def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, >> reglist:$dsts, variable_ops), >> IndexModeNone, LdStMulFrm, IIC_iLoadm, >>...

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 d...

Hi, After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: // A list of registers separated by comma. Used by load/store multiple. def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts, variable_ops), IndexModeNone, LdStMulFrm, IIC_iLoadm, "ldm${addr:submode}${p}\t$addr, $dsts&q...

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`...