similar to: [LLVMdev] tablegen pattern

I have added a few PPC-specific DAG combines in the past that follow this pattern on specific operations. Now that it appears that this would be useful to do on yet another operation, I'm wondering what people think about doing this in the target-independent DAG Combiner for any legal/custom operation on the target. TL; DR; The generic pattern would look like this: (build_vector (op

Hi all, I am writing a back-end for a processor that has complex type registers. It has two functional units to perform complex multiplications. From clang, I emulate a complex multiplication using vectors and, at the IR, I got this tblgen-friendly pattern (real component) : (set RARegs:$dst, (insertelt RARegs:$src, (i16 (trunc (add (ncmul (sext (i16

Thanks so much for your feedback Simon. I am not sure that what I am proposing here is at odds with what you're referring to (here and in the PR you linked). The key difference AFAICT is that the pattern I am referring to is probably more aptly described as "reducing scalarization" than as "vectorization". The reason I say that is that the inputs are vectors and the output

On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan <ivanllopard at gmail.com> wrote: > Hi all, > > I am writing a back-end for a processor that has complex type registers. > It has two functional units to perform complex multiplications. >  From clang, I emulate a complex multiplication using vectors and, at > the IR, I got this tblgen-friendly pattern (real component) : >

Hi, I have an issue with pattern matching. I have the following SelectionDAG: t13: i32 = extract_vector_elt t2, Constant:i64<1> That I am trying to match with the following pattern: def : Pat<(extractelt (v4i16 SingleReg:$v), 1), (SRADd1 SingleReg :$v, (i64 16))>; But for some reason the pattern does not match. It seems to be due to the fact extract_vector_elt's result

On Dec 9, 2011, at 4:12 PM, Ivan Llopard wrote: > Hi Eli, > Thanks for your response. Please see my responses below. > > On 10/12/2011 00:28, Eli Friedman wrote: >> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >>> Hi all, >>> >>> I am writing a back-end for a processor that has complex type registers.

Absolutely. We do it for scalars, so it would likely be a matter of just extending it. But that is one example. The issue of extracting elements, performing an operation on each element individually and then rebuilding the vector is likely more prevalent than that. At least I think that is the case, but I'll do some analysis to see if it is so or not. On Sat, Jan 11, 2020 at 6:15 PM Craig

On Fri, Dec 9, 2011 at 4:12 PM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Eli, > Thanks for your response. Please see my responses below. > > > On 10/12/2011 00:28, Eli Friedman wrote: >> >> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> >>  wrote: >>> >>> Hi all, >>> >>> I am writing

Hi Eli, Thanks for your response. Please see my responses below. On 10/12/2011 00:28, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >> Hi all, >> >> I am writing a back-end for a processor that has complex type registers. >> It has two functional units to perform complex multiplications. >> From clang,

Hi all, I’m not sure if this is the right list, so apologies if not. Doing some profiling I noticed some of my hand-tuned matrix multiply code with NEON intrinsics was much slower through a C++ template wrapper vs calling the intrinsics function directly. It turned out clang/LLVM was unable to eliminate a temporary even though the case seemed quite straightforward. Unfortunately any loads

On 10/12/2011 01:32, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:12 PM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Eli, >> Thanks for your response. Please see my responses below. >> >> >> On 10/12/2011 00:28, Eli Friedman wrote: >>> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> >>> wrote:

I'm trying to debug a problem with our custom backend with using a tiered register allocation setup. Just a little background. My target uses vec4 32bit registers and I want to have three levels of registers setup. Each vec4 register can have two sub-regs of size vec2 32bit, and each sub-reg, has its own two sub-regs of 32bit each. So it looks like this, xyzw -> {xy, zw} -> {x, y, z,

On Jul 1, 2011, at 12:16 PM, Villmow, Micah wrote: > I'm trying to debug a problem with our custom backend with using a tiered register allocation setup. > > Just a little background. My target uses vec4 32bit registers and I want to have three levels of registers setup. > Each vec4 register can have two sub-regs of size vec2 32bit, and each sub-reg, has its own two sub-regs of

Thanks, I think it can solve my problem. But please allow me to explain the hardware in detail. Hope there is more elegant way to solve it. The hardware is a "stream processor". That is, It processes samples one by one. Each sample is associated with several 128-bit four-element vector registers, namely: * input registers - the attributes of the sample, the values of the registers

Hello, My input language has support for 3 and 4 element vectors but my target only has support for the latter. The language defines vec3 with the same storage space as vec4 so from a backend perspective they are both the same. I'd really like if I could have LLVM treat vec3 as vec4 but I haven't found out how. Currently the target has emulated support for vec3 through LLVM. Loads are

From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Friday, July 01, 2011 2:56 PM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] (no subject) On Jul 1, 2011, at 12:16 PM, Villmow, Micah wrote: I'm trying to debug a problem with our custom backend with using a tiered register allocation setup. Just a little background. My target uses vec4 32bit registers and

Hello guys, Thanks for your help when you are busing. I am working on an open source project. It supports shader language and I want JIT feature, so LLVM is used. But now I find the ABI & Calling Convention did not co-work with MSVC. For example, following code I have: struct float4 { float x, y, z, w; }; struct float4x4 { float4 x, y, z, w; }; float4 fetch_vs( float4x4* mat

On Jun 27, 2008, at 8:02 AM, Stefanus Du Toit wrote: >>>> <result> = shufflevector <a x <ty>> <v1>, <b x <ty>> <v2>, <d x >>>> i32> >>>> <mask> ; yields <d x <ty>> >>> >>> With the requirement that the entries in the (still constant) mask >>> are >>> within

Hi, * Is there a way to setup LLVM to automatically convert vec3s to vec4s? Yes, if you specify v3i16 and friends as "promote" instead of "legal", llvm will promote it to a v4i16. The ARM NEON backend does this already. I'm surprised you haven't got this happening already as you mention that LLVM widens your loads to 4-element vectors. (this should happen during

i'm getting a Could not infer all types in pattern! error in my backend. it is happening on the following instruction: VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). how do i make it use appropriate types? in other words if it is f32 then use v4v32 and if it is i32 then use v4f32. i'm not sure even where to start? any help is appreciated.