similar to: [LLVMdev] Seperating registers in target description string replacement without adding whitespace?

I believe that table gen builds MipsGenAsmMatcher.inc which has the Match routines like MatchRegisterName(). In building MipsGenAsmMatcher.inc I am hitting the following issue (actually several, but they may be related). It may have something to do with the $$ escape sequence: /home/jcarter/workarea/llvm/lib/Target/Mips/Mips64InstrInfo.td:173:1: error: error: unable to find operand:

This variant works: class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, (outs CPU16Regs:$rx), (ins CPU16Regs:$ry, CPU16Regs:$rz), // !cast<FRRR16_ins>(I).OutOperandList, // !cast<FRRR16_ins>(I).InOperandList, !cast<FRRR16_ins>(I).AsmString, [(set CPU16Regs:$rx,

I think that what I did originally should have worked and the bug was correct as I reported it. Here is an alternate implementation which has the same problem. class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, !cast<FRRR16_ins>(I).OutOperandList, !cast<FRRR16_ins>(I).InOperandList,

class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern, InstrItinClass itin> : // ... This class has template args. You don't specify them in the first template arg of class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>: // ... --Sean Silva On Tue, Jul 3, 2012 at 2:29 PM, reed kotler <rkotler at mips.com> wrote: > Not sure what you mean.

I'm getting this incompatible type assertion when I run tblgen on my .td files: llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::DefInit; Y = llvm::Init; typename llvm::cast_retty<X, Y*>::ret_type = llvm::DefInit*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible

In our generated asm code we've got a constraint such that two registers in a ternary op have to be in different "banks", best illustrated with an example: add r1,r2,r1 # r1 <- r2 + r1 The problem here is that the first operand (the receiver of the value) is in the same "bank" as the 3rd operand (r1 again). This will cause an extra cycle to be burned. As it turns

I've filed the following bug. Maybe I'm doing something stupid here or maybe someone knows of a workaround. The following fragment from mips16 (not yet checked into main source). The problem is that I should be able to pass parameters: I.OutOperandList, I.InOperandList But instead, I must back substitute what I know the values of these are. (outs CPU16Regs:$rx), (ins CPU16Regs:$ry,

I think you're missing the template args for `FRRR16_ins` in the first argument. The switch in TGParser::ParseType() doesn't cover the case of types with template args though... which makes me wonder what is going on inside of TableGen to make `I.f` and `I.AsmString` valid... --Sean Silva On Mon, Jul 2, 2012 at 8:07 PM, reed kotler <rkotler at mips.com> wrote: > I've filed

Not sure what you mean. I.OutOperandList == (outs CPU16Regs:$rx) I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz) On 07/02/2012 09:26 PM, Sean Silva wrote: > I think you're missing the template args for `FRRR16_ins` in the first > argument. The switch in TGParser::ParseType() doesn't cover the case > of types with template args though... which makes me wonder what is

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

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

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

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 -

Hi Alex, So far, the code you've mentioned only defines a couple tablegen classes but doesn't define the instruction itself. To define the instruction you will also need a 'def' statement. For MIPS MSA, this statement looks like this: def LD_D: LD_D_ENC, LD_D_DESC; This defines an instruction (LD_D) with the encoding specified by the LD_D_ENC class, and the operation

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:

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'm working in adding support for 64-bit integers to my target. I'm using LLVM to decompose the 64-bit integer operations by using 32-bit registers wherever possible and emulating support where not. When looking at the bit shift decomposition I saw what seems to be a bug in the implementation. The affected function is ExpandShiftWithUnknownAmountBit in LegalizeIntegerTypes.cpp.

Hi all, My question is related to the register usage in instruction definition at TARGETInstrInfo.td file. I have defined new Target with it Registers and instructions. Now I need to generate an instruction like: mov MYREG1_NAME, MYREG2_NAME for the built-in function taking one constant integer argument, such as "__builtin_my_function_name(88)" I wondering whether it is possible

As previously discussed in an RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base

On Thu, 13 Dec 2018 at 21:41, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 12/13/2018 6:25 AM, Alex Bradbury wrote: > > There's also likely to be cases where you want to calculate the demanded bits > > in order to determine if e.g. a W-suffixed instruction can be selected for > > `(somoeop (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))`. This is easy to match