similar to: [LLVMdev] #ifdef in TableGen

On Feb 13, 2009, at 1:09 AM, Alex wrote: > > Is there something similar to #ifdef ... #endif in C supported in > TableGen *.td files? Not as such, what are you trying to do? -Chris

Chris Lattner-2 wrote: > > Not as such, what are you trying to do? > For example, sometimes I want some patterns to be matched by one machine instruction and sometimes two or more. I am doing the development for an experimental compiler and nothing is sure. I have source code in the backend looking for some specific opcode and they are conditional compiled (controllled by

Manjunath, I asked this question recently, but instead of telling you to search the archive I'm going to take it as a chance to recall how to do it (because I'll do so anyway and even telling tablegen to use an enum for instructions is not as trivial to do as you might think : ) I wrote it up in the wiki at http://wiki.llvm.org/HowTo:_Add_arbitrary_properties_to_instructions Regards,

I want to add a set of "properties" to each instruction in my instruction set, and want to be able to query that in my machine-specific optimizations. My Insts.td file looks as follows : class InstProperty; def propX : InstProperty; def propY : InstProperty; def propZ : InstProperty; class myInst<..., list<InstProperty> props> : Instruction { ... ...

Christian, Thanks for your reply and the wiki entry. I did search the archives, but evidently I didn't search for the right thing. My bad. Anyways, I am still wondering about the other part of my question. Why aren't there Tablegen backends specific to some architecture backends? Let me describe a different scenario. Suppose my architecture has vector and scalar units, and suppose I want

Hi Hal, I will try to explain the functionality using a simple example. Let's say that we have three formats for 'ADD' instruction and we want to relate them. ADD - non-predicated form ADD_pt : predicate true ADD_pf : predicate false We can define the relationship between the non-predicated instructions and their predicate formats as follows: def getPredOpcode : InstrMapping { //

Jyotsna, I hadn't been following this, so I apologize if this has already been provided, but can you give a quick example of how this functionality is used? Thanks in advance, Hal On Tue, 28 Aug 2012 13:01:17 -0500 "Jyotsna Verma" <jverma at codeaurora.org> wrote: > Hi Jakob, > > Here is the first draft of the patch to add TableGen backend support > for the

On 7/13/2020 21:30, Thomas Lively via llvm-dev wrote: > Part of the problem is that ISel patterns are like their own DSL inside > the TableGen DSL, so keywords like "ins", "outs", and "ops" aren't > keywords at the TableGen level, but rather at the level of the ISel > system implemented with TableGen. Copying existing patterns and reading > the

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

Is there a backend to Tablegen which can dump a map of pattern-to-matched to instruction-to-be-generated? --help doesn't seem to indicate anything like that. On Tue, Jul 14, 2020 at 2:13 PM Rotate Right <rightrotate5 at gmail.com> wrote: > Thanks Matt and Thomas. I will go through them. > > On Tue, Jul 14, 2020, 1:35 PM Matt P. Dziubinski <matdzb at gmail.com> wrote:

> All of the tablegen backends work this way. As you mentioned, > there are no target-specific tablegen backends at present. > > The underlying observation here is that features are never > fundamentally "specific for a target". For example, a mapping > between vector opcodes and associated scalar opcodes could > reasonably be made on many architectures. Even >

Dan, > In general, it's a design goal to structure CodeGen features as > target-independent code parameterized with target-specific data. > The degree to which this goal is met in LLVM CodeGen features today > varies, but features that have been implemented using TableGen have > been relatively successful. Can you give an example of a relatively successful instance where

On Jun 8, 2009, at 1:25 PM, Manjunath Kudlur wrote: > Dan, > > >> In general, it's a design goal to structure CodeGen features as >> >> target-independent code parameterized with target-specific data. >> >> The degree to which this goal is met in LLVM CodeGen features today >> >> varies, but features that have been implemented using TableGen

On Mar 9, 2011, at 2:13 PM, Lu Mitnick wrote: > Hello all, > > I have some question about usage of TableGen when adding a new LLVM Backend. There are three place to use TableGen in basic steps of document "Writing an LLVM Compiler > Backend": > > 2. Describe the register set of the target. Use "TableGen" to generate code for register definition, register

Hello all, I have some question about usage of TableGen when adding a new LLVM Backend. There are three place to use TableGen in basic steps of document "Writing an LLVM Compiler Backend": 2. Describe the register set of the target. Use "TableGen" to generate code for register definition, register aliases, and register classes from a target-specific RegisterInfo.td input

Each of the main TableGen files for the supported targets includes include "llvm/Target/Target.td" In turn, Target.td includes include "llvm/IR/Intrinsics.td" The final lines of Instrinsics.td are include "llvm/IR/IntrinsicsPowerPC.td" include "llvm/IR/IntrinsicsX86.td" include "llvm/IR/IntrinsicsARM.td" include

Hello Jakob, Is this means that TableGen execution is handled in Makefile. Porting programmer doesn't need to execute TableGen by hand? thanks 2011/3/10 Jakob Stoklund Olesen <stoklund at 2pi.dk> > > On Mar 9, 2011, at 2:13 PM, Lu Mitnick wrote: > > > Hello all, > > > > I have some question about usage of TableGen when adding a new LLVM > Backend. There

Now that I've learned my way around TableGen just a bit, I'd like to solicit suggestions for improving and enhancing it. Perhaps there are some lexical changes that could improve readability of .td files (e.g., I'm planning to enhance the lexer to allow an apostrophe as a digit group separator in integers, a la C++). Perhaps there are some syntactic enhancements that would make .td

Hi all, I'm working on llvm assembler support for Mips and for a while I'm trying to solve a problem regarding complex macro instructions. As mips assembler supports macro instructions that can develop to more then one real instruction depending on the operand type(usually two or three) we can't use InstAlias to exploit tableGen generated code. Currently we expand these in

This is the second in a series of occasional TableGen newsletters. The purpose is to inform the greater LLVM community of changes and enhancements to TableGen and its backends. * As announced previously, there are two new TableGen documents and three updated ones: TableGen Overview --- https://llvm.org/docs/TableGen/ TableGen Programmer's Reference ---