search for: instrmappings

Hal, that’s a good point. There are more manually-maintained tables in the X86 backend that should probably be tablegened: the memory-folding tables and ReplaceableInstrs, to name a couple. If you have ideas on how to get these auto-generated, please let us know. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Wednesday, November 23, 2016

Hi Jacob, Your suggestion worked for the simple relations between instructions as you've included in your example. With one small change, I am able to represent more complex relations as well. In the Hexagon backend, a predicated instruction can translate into another form called 'predicate new'. So, in our example of 'ADD', we can have another transformation like this -

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

Hi Jacob, Thanks for the suggestions. I have a few questions here. > You are on to something here, but you don't need to define a 'Relations' class > on top of the tablegen records. They are already relations, you just need the > proper query language to match the instructions you want. Are you saying that the mechanism is already present which allows us to relate

...me playing around with GlobalISel on the AMDGPU target, and I was wondering if there is any reason to have RegisterBankInfo::getInstrAlternativeMappings() and RegisterBankInfo::getInstrMapping() as separate functions. Could we instead replace these two functions with just one: RegisterBankInfo::getInstrMappings() and then just treat the first mapping in the list as the 'default' mapping to use for 'Fast' RegBankSelect mode? The reason this would make sense (at least for the AMDGPU target) is because both functions need to do the exact same analysis in order to compute the cost and order f...

On Aug 17, 2012, at 10:02 AM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: > > Hi Jacob, > > Thanks for the suggestions. I have a few questions here. > >> You are on to something here, but you don't need to define a 'Relations' > class >> on top of the tablegen records. They are already relations, you just need > the >>

On Aug 20, 2012, at 1:32 PM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: > In the Hexagon backend, a predicated instruction can translate into another > form called 'predicate new'. So, in our example of 'ADD', we can have > another transformation like this - > > ADD--- ---> ADDtrue -----> ADDtru_new (predicate new form of true) >

On Aug 16, 2012, at 1:39 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > Hi Everyone, > > After some more thoughts to the Jacob's suggestion of using multiclasses for > Opcode mapping, this is what I have come up with. Please take a look at the > design below and let me know if you have any suggestions/questions. Hi Jyotsna, You are on to something here, but you

You're right. I can have use RowFields for that purpose. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Monday, August 20, 2012 3:42 PM To: Jyotsna Verma Cc: 'Tony Linthicum'; llvmdev at cs.uiuc.edu Subject: Re: TableGen related question for the Hexagon

Hello LLVM, My target has a complex relaxation hierarchy. Perhaps a modest TableGen extension would help consolidate most of the work involved in choosing a relaxed opcode. I also notice the x86 relaxation code with a comment wondering if TableGen could improve life. Does the following outline sound interesting? 1) Add a new field of type 'Instruction' to the Instruction class called

For example, given a multiclass for ADD 32 bit that might produce something like: ADD32_REG_REG_REG (operands are all registers for a 32 bit add) ADD32_REG_IMM_REG (srcA is a register, srcB is an immediate and dst is a register) ADD32_REG_IMM_MEM (srcA is a register, srcB is an immediate and dst is a memory address) What I'd like to do is replace an operand, for example, change srcA from a

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

Hi All. This is an RFC for a proposed target specific X86 optimization for reducing code size in the encoding of AVX-512 instructions when possible. When the AVX512F instruction set was introduced in X86 it included additional 32 registers of 512bit size each ZMM0 - ZMM31, as well as additional 16 XMM registers XMM16-XMM31 and 16 YMM registers YMM16-YMM31. In order to encode the new registers of

I would like a command line option to disable this optimization. That way tests can still verify that EVEX instructions came out of isel by using -show-mc-encoding. On Wed, Nov 23, 2016 at 5:01 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > ------------------------------ > > *From: *"Gadi via llvm-dev Haber" <llvm-dev at lists.llvm.org> >

Hi Everyone, After some more thoughts to the Jacob's suggestion of using multiclasses for Opcode mapping, this is what I have come up with. Please take a look at the design below and let me know if you have any suggestions/questions. I have tried to keep the design target independent so that other targets could benefit from it. 1) The idea is to add 3 new classes into

Jakob, One more question. You had suggested 'ValueCols' as of type list<list<string> >. Does the TableGen know how to extract it? It appears to me that we may have to add support for that. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

> I would like a command line option to disable this optimization. That way tests can still verify that EVEX instructions came out of isel by using -show-mc-encoding. I think that keeping tests compatibility is not a reason for an additional “llc” flag. We check encoding in test/MC/X86 dir. Is there any option to report-out from llc in non-debug mode? It should be an option to control

Matt, so in AMDGPU, the operands are sort of 'generic'? Can you point me to the right places? Thanks. On Wed, Apr 12, 2017 at 1:36 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 04/12/2017 10:25 AM, Ryan Taylor via llvm-dev wrote: > > For example, given a multiclass for ADD 32 bit that might produce > something like: > > ADD32_REG_REG_REG

Hi Jakob, Here is the first draft of the patch to add TableGen backend support for the instruction mapping tables. Please take a look and let me know your suggestions. As of now, I create one mapping table per relation which results into a long .inc file. So, I'm planning to combine everything into a single table and will include APIs (one per relation) to query from this table. Thanks,