similar to: BUILD_VECTOR disambiguation

Thanks for the clarification. The `except` seemed dangling to me, but it's early here. Just curious... how do we end up with a mixed type BUILD_VECTOR? That's counterintuitive. On Tue, Jul 7, 2020 at 10:58 AM Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Mixed integer types are ok, but the values will get truncated to the element type of the output

Mixed types aren't allowed. They are checked for in VerifySDNode in SelectionDAG.cpp and will fail an asserts build. ~Craig On Tue, Jul 7, 2020 at 8:25 AM Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The problem can happen when you want to build a vector of i8, but i8 > itself is not legal on your target. All operands to BUILD_VECTOR will be >

i'm having difficulty in understanding the BUILD_VECTOR instruction and how to lower it to the an actual ISA. i looked at other targets but wasn't quite able to figure it out. would someone be able to dumb it down for me? assume i have an insert element instruction which inserts an element from a GPR to a Vector Register at a given index, i..e vset <vector register> <gpr>

Hi all, While working on a patch to improve codegen for fadd reductions on AArch64, I stumbled upon an outstanding issue with the experimental.vector.reduce.fadd/fmul intrinsics where the accumulator argument is ignored when fast-math is set on the intrinsic call. This behaviour is described in the LangRef (https://www.llvm.org/docs/LangRef.html#id1905) and is mentioned in

I have two patterns in tablegen that do look like the exact same thing: Pat 1) def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins i16imm:$val), asm, [(set GPRV4I16:$dst, (build_vector (i16 imm:$val)))]>; Pat 2) def v4i16imm : Operand<v4i16>; def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins v4i16imm:$val), asm, [(set

Hello, I'm working on extending the current PowerPC backend to handle a vector instruction set for floating-point operations (IBM's double-hummer instruction set used on the BG/P supercomputers). In this instruction set, each of the existing floating-point registers becomes the first of two vector elements. I am having trouble optimizing the BUILD_VECTOR operation for the case where I am

Just spitballing... why not have a splat construct straight through LLVM? It would make the IR more readable, opposed to the insert+shuffle method. On Thu, Aug 29, 2019 at 19:06 Amara Emerson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 to a new node, we’d very likely do the same thing for GlobalISel and > move to a canonical spat representation for all targets. > >

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 Bob, > LLVM's type legalizer is changing the types of BUILD_VECTORs in a way > that seems wrong to me, but I'm not sure if this is a bug or if some > targets may be relying on it. > > On a 32-bit target, the default action for legalizing i8 and i16 types > is to promote them. If you then have a BUILD_VECTOR to construct a > legal vector type composed of

On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com> wrote: > LLVM's type legalizer is changing the types of BUILD_VECTORs in a way > that seems wrong to me, but I'm not sure if this is a bug or if some > targets may be relying on it. > > On a 32-bit target, the default action for legalizing i8 and i16 types > is to promote them. This isn't

LLVM's type legalizer is changing the types of BUILD_VECTORs in a way that seems wrong to me, but I'm not sure if this is a bug or if some targets may be relying on it. On a 32-bit target, the default action for legalizing i8 and i16 types is to promote them. If you then have a BUILD_VECTOR to construct a legal vector type composed of i8 or i16 values, the type legalizer will

On Feb 2, 2009, at 1:51 PM, Eli Friedman wrote: > On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com> > wrote: >> LLVM's type legalizer is changing the types of BUILD_VECTORs in a way >> that seems wrong to me, but I'm not sure if this is a bug or if some >> targets may be relying on it. >> >> On a 32-bit target, the default

Hi All, First of all, I am not native English speaker. While reading BUILD_VECTOR related code, for example, PPCTargetLowering::LowerBUILD_VECTOR, I see "splat" here and there. Could someone explain what it is (does splat mean the same thing across the whole code base)? Besides, from my English dictionary, I don't know why we call such thing as "splat"... :p Regards,

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 Feb 2, 2009, at 1:22 PM, Duncan Sands wrote: > another way this could be done is to say that the operands of a > BUILD_VECTOR don't have to have the same type as the element type > of the built vector. Then when the type legalizer sees a > v4i16 = BUILD_VECTOR(i16, i16, i16, i16) it can turn this into a > v4i16 = BUILD_VECTOR(i32, i32, i32, i32) and it will be happy >

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

How should I go about matching floating-point addsub-like vector instructions? My first inclination is to write something which matches build_vector 1.0, -1.0, and then use that in combination with a match on fadd, but that does not seem to work. I think this is because BUILD_VECTOR cannot ever be "Legal", and so it is always turned into a constant load before instruction selection.

On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a

Hi Hal, you should probably add a target specific DAG combine that synthesizes the appropriate target instruction. This is how I handled x86 horizontal add (see the FHADD X86 opcode). If it turns out that the same thing is useful for other targets then it can be generalized later. Ciao, Duncan. On 10/18/11 00:40, Hal Finkel wrote: > How should I go about matching floating-point addsub-like

On Nov 9, 2009, at 6:11 PM, Dale Johannesen wrote: > PPC Altivec supports vector type v16i8 (and others) where the element > type is not legal (in llvm's implementation). When we have a > BUILD_VECTOR of these types with constant elements, LegalizeTypes > first promotes the element types to i32, then builds a constant pool > entry of type v16i32. This is wrong. I can