similar to: [LLVMdev] Creating a tablegen backend

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

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

Can anyone offer me any advice on writing a new backend for tablegen? I think I want to look at CodeGenDAGPatterns.cpp, but I'm not that familiar with the code yet. I want to translate X86 (or other) binary into an in-house intermediate language. If this is easy to do with LLVM-IR, that would be great, too, though for now I ultimately need to target this other language. I would greatly

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

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,

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

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,

Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not much at all on the Global ISel scheme, I'm tempted to work on the former and then the latter. So I'll look at the CodeGenDAGPatterns messages first. Then I will take a look at Global ISel. Matt: Can you suggest one or two things about Global ISel that could use some work? I won't get to it quickly, but it will

Hi, I implemented a pattern matching of the dot product for arm64 and it seemed to work well for the basic case, i.e., class mulB<SDPatternOperator ldop> : PatFrag<(ops node:$Rn, node:$Rm, node:$offset), (mul (ldop (add node:$Rn, node:$offset)), (ldop (add node:$Rm, node:$offset)))>; class mulBz<SDPatternOperator ldop> : PatFrag<(ops node:$Rn,

Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is it easy to post an example? At 11/18/2020 01:55 PM, Thomas Lively wrote: >Hi Paul, > >I think this would be time well spent. At least in the WebAssembly backend, the vast majority of our ISel work is still done with DAG ISel. I know this is different from the performance work you have in mind, but one of my

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,

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,

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!

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

Yes, the CodeGenDAGPatterns is exactly right. Try applying the patch below and rebuilding and you'll see what I mean about the error messages ;) That being said, I'm sympathetic to Matt's point about shifting effort to GlobalISel. Maybe it has similar problems you could work on? A nicer development experience would certainly be a good carrot to get me excited to switch over sooner.

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

Hello, Edd > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node > > type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function > > "ApplyTypeConstraints" Could you please try with gcc 4.x and check, whether