similar to: [LLVMdev] bug in tablegen?

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,

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

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.

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

Hello. I have problems specifying vector instructions with immediate values in TableGen. I wrote the following specification (I got inspired from the MSA vector instructions for the Mips back end): class MSA_I16_FMT<bits<9> opcode>: MSAInst { bits<16> s16; let Inst{31-23} = opcode; let Inst{26-11} = s16; }

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 Alex, On 5 December 2016 at 18:00, Alex Susu <alex.e.susu at gmail.com> wrote: > We can compile it. Note that this is the only compilable code w.r.t. > using i64 or i64imm (in the 2 lines above: "dag InOperandList", "list<dag> > Pattern"). Yeah, you actually want to use "imm": list<dag> Pattern = [(int_repeat_x_times imm:$imm)];

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

----- Original Message ----- > From: "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

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

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, Rm{4}, Rm{3},

if I write: int z, x; ... z = (x >= k); -- where k is a constant The compiler always wants to translate this into: z = (x > (k-1)); In general this can often lead to better code (and it does for Mips 16 for sure), except at the boundary condition where k==-32768 Then it creates the literal -32769 which cannot be placed in a simple immediate field. That creates a lot of extra code for

I am trying to make some modifications to our code generator that will produce better code, but require adding new patterns. What I am trying to do is take a register/register pattern and change it to a register/immediate. So for example, I have this pattern: class ILFormat<ILOpCode op, dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { let Namespace =

I'm not at the machine that has the changes, but it was failing at index 0. Micah From: Owen Anderson [mailto:resistor at mac.com] Sent: Thursday, April 19, 2012 3:35 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Tablegen to match a literal in an instruction Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output

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:

I saw many definitions derived from Instruction defines OutputOperandList and InputOperandList (usually in the xxxInstrFormats.td), but I don't see where they are referenced. Anything I missed here? Thanks, -Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140112/e6e87e9f/attachment.html>

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

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

Here is a simple place I wanted to use it. ... On multiply, the result implicit is placed in a 64 bit hi/lo register. // // Format: MFLO rx MIPS16e // Purpose: Move From LO Register // To copy the special purpose LO register to a GPR. // def Mflo16: FRR16_M_ins<0b10010, "mflo", IIAlu> { let Uses = [LO]; let neverHasSideEffects = 1; } // // Pseudo Instruction for mult //