search for: decodermethods

Hi, That's what the DecoderMethod is for. Similarly ParserMatchClass for the asm parser and PrintMethod for the asm printer: def CondCodeOperand : AsmOperandClass { let Name = "CondCode"; } def pred : PredicateOperand<OtherVT, (ops i32imm, i32imm), (ops (i32 14), (i32 zero_reg))> { let PrintMethod = "printPredicateOperand";

A question for LLVM code generator developers: After having read through "The LLVM Target-Independent Code Generator" [1] I'm unclear about what precisely the objects MCInst and MCOperand represent. They sit in the space between assembly syntax and binary encodings, but which are they modeling? For example, a Thumb 2 branch instruction 'b' takes an immediate. That syntax

I'm currently trying to get llvm-mc --disassemble working for the XCore backend. Up until recently there was no instruction encoding / decoding information on any of the XCore instructions so Im incrementally adding this information at the same time as adding tests for the disassembler. However I've run into a problem and I'm not sure of the best way to solve it. With some of the

Hi In my MC6809 backend, in llvm/lib/Target/MC6809/InstPrinter/MC6809InstPrinter.cpp, I have the routine void MC6809InstPrinter::printPCRelImmOperand(const MCInst *MI, unsigned OpNo, raw_ostream &O) { const MCOperand &Op = MI->getOperand(OpNo); ZZ if (Op.isImm()) { int64_t Imm = Op.getImm() + 2; <<<======================== O << "$"; if (Imm

Owen, As I recall, we had some similar issues with custom decoders needing to cooperate on ARM. Do you remember the details? -Jim On Dec 18, 2012, at 2:37 AM, Richard Osborne <richard at xmos.com> wrote: > I'm currently trying to get llvm-mc --disassemble working for the XCore backend. Up until recently there was no instruction encoding / decoding information on any of the XCore

Owen is correct in his descriptions. The MCOperand values are intended to model the instruction encoding. Where that doesn't match the assembly syntax, the asm parser (and codegen) and the instruction printer are responsible for encoding/decoding the values. For targets that predate the MC layer, this isn't always the case, leading to things being a bit confusing when just reading the

Hello, I'm trying to define in my new back end, in MyBackendInstrInfo.td file, a vector load instruction that takes an immediate address operand. (I got inspired from Mips' MSA SIMD extensions.) Could you please tell me what's the right way to do it? Here, the load class has $addrsrc which is a relative address with base a certain register and offset: class

Hi all, Short version I get decoding conflicts during generation of disassembler tables for my modified PowerPC backend: 001100.......................... ................................ ADDIC 001100__________________________ E_LBZ 001100__________________________ Which methods can be used to resolve this kind of error? Long version: I'm trying to implement support for the PowerPC

I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x respectively, the imm matches but it prints out -32768 (which is invalid for sub16u). We are using uimm16 not match unsigned but for PrintMethod, effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why simm16 matches and uimm16 does not. Here is the pattern if that helps at all. So just as a

Hello. I have extended the BPF back end with vector registers (inspiring from Mips MSA) - something like this: def MSA128D: RegisterClass<"Connex", [v128i16], 32, (sequence "Wh%u", 0, 31)>; I also added vector store and load instructions in the style of Mips MSA - see

Hello James, that was also what I've planned to do but just wasn't sure. Thanks for that. On Mon, Dec 14, 2015 at 11:52 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > You can't nest operands like that - it must be a flattened list. So: > > def *Xpred* : PredicateOperand<OtherVT, (ops *i32imm, i32imm*, i32imm), > (ops (i32 14), (i32

Hi, I've instruction scheduling problem that I cannot further investigate by myself... Could someone give me some clues? After Instruction selection, here is part of the generated instruction. NOP MOV_AB_ro @s1, %fab_roff0 %6:fpuaoffsetclass = COPY %fab_roff0; FPUaOffsetClass:%6 MOV_A_oo %6, def %5; FPUaOffsetClass:%6,%5 MOVSUTO_A_iSLo 24575, def %7;

Spills created at the end of the block (I assume you mean what fast regalloc does at -O0) are created long after instruction selection. In that case it sounds like your implementation of storeRegToStackSlot/loadRegFromStackSlot is broken -Matt On Tue, Oct 25, 2016 at 7:30 AM +0800, "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>

Where does the unsignedSub come from? On 2017-02-15 20:38, Ryan Taylor wrote: > Sorry, it should be: > > defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, > GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>; > > On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> I see. If I put simm16 and

Hello. Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have to say that the definition of the "multiclass avx512_gather" from lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it. I currently have some serious problems with TableGen - it gives an assertion failure:

Hi all, I started to write an LLVM backend for custom CPU. I created XXXInstrInfo but there are some problems. I searched for it but I couldn't find anything. Can anyone help me? include "XXXInstrFormats.td" def simm16 : Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

Ok, Scratching the surface this morning on Bug 1388. Happy to find that CCR has already been defined in ARMRegisterInfo.td However all uses in the instruction info tablegen files indicate that a two-value operand can't be used where a dag node expects two operands. // FIXME: should be able to write a pattern for ARMBrcond, but can't use // a two-value operand where a dag node

Hi, I have added Branch condition BGEID like below… *def : Pat<(brcond (setcc (i32 GR32:$L), (i32 GR32:$R), SETGE), bb:$T),* * (BGEID (CMP GR32:$L, GR32:$R), bb:$T)>;* *def BGEID : TBT<0b101110, (outs), (ins GR32:$ra, brtarget:$offset), "bgeid\t$ra,$offset", [], IIC_BRc> {* * let rd = 0b10101;* *}* *def brtarget : Operand<OtherVT>* *{*