search for: registeroperands

Hello. Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have to say that the definition of the "multiclass avx512_gather" from lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it. I currently have some serious problems with TableGen - it gives an assertion failure:

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hi Alex, I don’t know too much about recent MIPS, but have recently been doing something similar for the new ARM SVE architecture, so hopefully this will get you closer to what you need: If you’re looking where I think you are (lib/Target/X86/X86InstrAVX512.td), ‘GatherNode’ is a template argument, not a definition. It allows a PatFrag be passed into the avx512_gather multiclass definition.

Hello, I'm trying to define in my new back end, in MyBackendInstrInfo.td file, a vector load instruction that takes an immediate address operand. (I got inspired from Mips' MSA SIMD extensions.) Could you please tell me what's the right way to do it? Here, the load class has $addrsrc which is a relative address with base a certain register and offset: class

Hello, In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along with some follow-up patches) the PowerPC back end was changed to use types instead of register classes in instruction patterns. This matched similar changes that Jakob made for Sparc in r177835. I've recently come across an

Hi Sean, Just to give the GlobalISel perspective on this, GlobalISel supports the declaration of a zero register in the register class like so: def GPR32z : RegisterOperand<GPR32> { let GIZeroRegister = WZR; } With that definition, the tablegen-erated ISel code will try to replace will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is specified as GPR32z. >

On Tue, Jan 2, 2018 at 8:28 AM, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > Hi Sean, > > Just to give the GlobalISel perspective on this, Thanks for chiming in! > GlobalISel supports the declaration of a zero register in the register > class like so: > def GPR32z : RegisterOperand<GPR32> { > let GIZeroRegister = WZR; >

Hello. I read on page 4 of http://www.cs.fsu.edu/~whalley/cda5155/chap4.pdf that gather and scatter operations exist for Mips, named LVI and SVI, respectively. Did anyone think of implementing in the LLVM Mips back end (part of the MSA vector instructions) gather and scatter operations? If so, can you share with me the TableGen spec? (I tried to start from LD_DESC_BASE, but it

Hello. I have extended the BPF back end with vector registers (inspiring from Mips MSA) - something like this: def MSA128D: RegisterClass<"Connex", [v128i16], 32, (sequence "Wh%u", 0, 31)>; I also added vector store and load instructions in the style of Mips MSA - see

On May 17, 2013, at 2:04 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > Hello, > > In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and > http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along > with some follow-up patches) the PowerPC back end was changed to use > types instead of register classes in instruction

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

> On 3 Jan 2018, at 19:44, Sean Silva <chisophugis at gmail.com> wrote: > > > On Tue, Jan 2, 2018 at 8:28 AM, Daniel Sanders <daniel_l_sanders at apple.com <mailto:daniel_l_sanders at apple.com>> wrote: > Hi Sean, > > Just to give the GlobalISel perspective on this, > > Thanks for chiming in! > > GlobalISel supports the declaration of a zero

Spills created at the end of the block (I assume you mean what fast regalloc does at -O0) are created long after instruction selection. In that case it sounds like your implementation of storeRegToStackSlot/loadRegFromStackSlot is broken -Matt On Tue, Oct 25, 2016 at 7:30 AM +0800, "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>

I looked around the codebase and didn't see anything that obviously looked like the natural place to turn constant zero immediates into zero-registers (i.e. registers that always return zero when read). Right now we are expanding them in ISelLowering::LowerOperation but that seems too early. The specific issue I'm hitting is that we have a register that reads as -1 and so when we replace

Hi Alex, So far, the code you've mentioned only defines a couple tablegen classes but doesn't define the instruction itself. To define the instruction you will also need a 'def' statement. For MIPS MSA, this statement looks like this: def LD_D: LD_D_ENC, LD_D_DESC; This defines an instruction (LD_D) with the encoding specified by the LD_D_ENC class, and the operation

...tions for every > permutation of register and immediate operands, although I realize this is > what most targets seem to do. Then you can simply replace the operand of > the instruction rather than having to figure out the new opcode you need to > use. What AMDGPU does is define various RegisterOperands with custom types > that are allowed by the verifier to contain immediates. The same principle > should also work for mem operands. You could also try to define an > InstrMapping to get the other versions of the opcode. > > -Matt > -------------- next part -------------- An HTML a...

On Fri, 2013-05-17 at 15:32 -0700, Jakob Stoklund Olesen wrote: > On May 17, 2013, at 2:04 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > > Hello, > > > > In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and > > http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along > > with some follow-up

On 4 October 2016 at 19:50, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If there are no objections, I'd like to start working on this soon... > > For the AMDGPU target this implies that RC->getSize will no longer be > available in the MC layer. Another advantage of this work that hasn't been mentioned yet is it will reduce the number of uses

Hello. Sometimes the constraints imposed on an instruction's encoding are too complex to be described in tablegen alone. In such cases a custom decoder method is implemented. This makes sense when the decoding itself is very complex, but it is wasteful to do it only when checking additional constraints. This is because: 1. a custom decoder method has to decode operands, set opcodes, etc. -