similar to: [GlobalISel] Can we drop RegisterBankInfo::getInstrAlternativeMappings() ?

> On Feb 21, 2019, at 12:18 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Matt, > >> On Feb 20, 2019, at 4:49 PM, Arsenault, Matthew via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> Some operations on AMDGPU require operands which must be in a register

Hi, Some operations on AMDGPU require operands which must be in a register bank that is impossible to copy from another. The operation needs to be rewritten in a complex way to avoid the illegal copy. Currently if I correctly report the required register banks in the operand mapping, RegBankSelect happily inserts the illegal copies, somehow concluding they are cheap (I would at least hope

Hi, I’m looking at RegBankSelect’s partially implemented support for deciding to split a value between multiple registers and I’m wondering if it’s actually intended to solve the problem I’m trying to use it for. RegisterBankInfo.h has this example mapping table: /// E.g., /// Let say we have a 32-bit add and a <2 x 32-bit> vadd. We /// can expand the /// <2 x 32-bit> add into

Hi Quentin, I’ve started running an ABI test suite with global isel on AArch64, and while it hasn’t found any ABI issues it has hit an assertion in clang when using the __fp16 type. Here’s a reproducer: __fp16 pass_f16(__fp16 p) { return p; } $ /work/llvm/build/bin/clang --target=aarch64-arm-none-eabi -march=armv8-a -c test.c -O0 -mllvm -global-isel -mllvm -global-isel-abort=0

To give an update here, we actually are not missing a mapping. The code complains because we are copying around a fp16 into a gpr32 and that shouldn’t be done with a copy (default mapping). I extended the repairing code to issue G_ANYEXT in those cases instead of asserting. However, now, I have to teach instruction select about those ANYEXT otherwise we’ll fallback in that case. But that’s a

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values

> On Feb 26, 2019, at 7:25 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > > >> On Feb 26, 2019, at 4:18 PM, Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> wrote: >> >> >> >>> On Feb 26, 2019, at 7:01 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> >

Hi Quentin, My only remaining concern is around ABI compatibility. The following commit seems to indicate that in the previous round of evaluation, we didn’t find an existing ABI compatibility issue: http://llvm.org/viewvc/llvm-project?view=revision&revision=311388. I haven’t looked into the details of this issue - so maybe I’m worried over nothing? I’m wondering if since then on your side

Hi Quentin, Am 08.10.20 um 21:17 schrieb Quentin Colombet: > Hi Dominik, > >> On Oct 8, 2020, at 5:03 AM, Dominik Montada >> <dominik.montada at hightec-rt.com >> <mailto:dominik.montada at hightec-rt.com>> wrote: >> >> Hi Quentin, >> >> thanks for picking up the conversation! >> >> > I think we should step back and

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

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