similar to: [LLVMdev] Tablegen backend HOWTO?

Durward, Why not use LLVM-IR as your 'generic assembly'? Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Durward McDonell > Sent: Thursday, August 19, 2010 2:02 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Creating a tablegen backend > > Hello. > > I would like to

Hello. I would like to create a new backend for tablegen that produces code in an generic assembly language (not for a real processor). The documentation page for this says "ToDo", but I think what I want to do is something similar to CodeGenDAGPatterns::ParseInstructions() in CodeGenDAGPatterns.cpp. Is this even vaguely correct? Any pointers would be appreciated. I'm

>  Why not use LLVM-IR as your 'generic assembly'? I should have been more specific about my goals.  I want to read a (x86) binary, and output code in this other language.  I do not have access to the source.  The target language might be negotiable, but for the moment is fixed at what it is.  My big hope is that I can leverage the semantics that are stored in the X86*.td files,

On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Are multi-output patterns in TableGen supposed to work, or is that a known limitation in the current implementation? It is a known limitation. You have to write C++ code to match patterns with multiple outputs. > > If I have TableGen code like the following... > > 1242 def SDTTestNode

It has been something we've talked about for years, but I'm not aware of anyone working on it right now. On Jan 6, 2013, at 5:34 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Thanks for the info. Is this on someone's list of things to do? > > > On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4,

Are multi-output patterns in TableGen supposed to work, or is that a known limitation in the current implementation? If I have TableGen code like the following... 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; 1244 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0,

Thanks for the info. Is this on someone's list of things to do? On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> > wrote: > > Are multi-output patterns in TableGen supposed to work, or is that a known > limitation in the current implementation? >

All, in working through the RISCV LLVM backend, I’m running into some trouble in defining the instruction formats for the system instruction. The system instructions follow a pre-defined instruction template (type-I), but differ in that they have no input registers (only the target). The system instructions are defined as: rdcycle Rt I’ve defined a stand-alone instruction definition (as

Hi Krzysztof, Today I try it on llvm9.0.0 version. &nbsp; def bos : RPPInstMMEMrr<OPC_STORE, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (outs), (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !strconcat(opcodestr, ""), "$rs1,

def STOREbos { // InstructionEncoding Instruction RPPInst RPPInstMMEMrr &nbsp; field bits<32&gt; Inst = { 0, 0, 0, 1, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; &nbsp; field bits<32&gt; SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Thank you so much. it run fine. Can you please resolve following issue; I now have support for v2048i32 but my backend supports v64i32 so ultimately v2048i32 needs to be split into 32 v64i32 instructions. the only difference between 2 is if its orginally v2048i32 i want my registers assignment from REG_A set. if its v64i32 originally, then i want registers from set REG_B. How to accomplish

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!

Hi, The full trace stack: Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824! [ 85%] Building X86GenEVEX2VEXTables.inc... &nbsp;#0 0x000000000081b9b5

Are you using isTarget = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1,

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pattern complexity = 8 cost

I would be very grateful if you specify whether there is some way to allocate registers (different order) / from different register sets to the same instruction based on the vector width/ no of iterations. I have tried several alternatives but could not succeed. Also I have asked this question many times but no one responds. Is there something wrong with this?? Kindly guide me. Thank You On

Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in

I would like to know why this patch https://reviews.llvm.org/D90973 had such a drastic size effect on the global isel tablegened matcher table for riscv. It only changed the DAG ISel table by about 15K. But the global isel table shrinks by over 200K. ~Craig On Wed, Nov 18, 2020 at 1:37 PM Paul C. Anagnostopoulos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Given that I'm

I’m hitting TableGen errors trying to match the smullohi <lhs> <rhs> node in TableGen. smullohi returns two results, which is the problem. I am not sure how to match against multiple results. The only other nodes to return two operands are umullohi, udivrem, and sdivrem. There are no examples of these in TableGen in tree. The closest I can get is this: set (R1, R0, (umullohi

Question: How hard should tblgen try to fit constants into a particular type? My case is an xor with i8 immediate where I'm using 0xff in as the immediate value. 0xff should fit into i8 if treated as unsigned, but CodeGenDAGPatterns.cpp assumes that any and all integers less than 32-bits are signed. Should tblgen try to see if the sign-extended version of the constant could fit into the