search for: build_vector

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 i1...

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 value. It's pretty much what the comment says. &gt...

...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 > legalized to the next legal integer type, so you can end up with a > BUILD_VECTOR of vNi8 where all operands are i32, for example. > > Actual mixed types are less likely to happen, but if you are doing your > own target-specific lowering, you can end up with mixed types, si...

Hey devs, >From ISDOpcodes.h... /// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a fixed-width vector /// with the specified, possibly variable, elements. The number of elements /// is required to be a power of two. The types of the operands must all be /// the same and must match the vector element type, except that integer types /// are al...

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 ve...

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. Specifically, in SDValue SelectionDAGLegalize::Lega...

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 true on x86. > If you then have a BUILD_VECTOR to...

...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 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. > > Specifically, in SDValue Se...

...rectly. The question here is how > best > to fix this while minimizing code duplication. This will doubtless be > fixed soon. Ok. > PowerPC/vec_spat.ll (@splat_h) - here code got slightly worse. The > problem here is that LegalizeDAG "cheats": it constructs a > BUILD_VECTOR > where the type of the operands doesn't match the vector element type > (this > is supposed to be illegal), while LegalizeTypes correctly constructs a > BUILD_VECTOR where the operand type is equal to the vector element > type, > but then the PPC custom code doesn't h...

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 action for legalizing i8 and i16 >> types >> is to promote them. > > This isn't true on x86....

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 > (all result and operand types are leg...

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 GPRV4I16:$dst, (v4i16 imm:$val))]>; The second pattern seems to build correctly, but doesn't match because of the bui...

(Resend, since it didn't seem to reach the mailing list the first time) 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 ve...

...ands which does not do CSE on calls correctly. The question here is how best to fix this while minimizing code duplication. This will doubtless be fixed soon. PowerPC/vec_spat.ll (@splat_h) - here code got slightly worse. The problem here is that LegalizeDAG "cheats": it constructs a BUILD_VECTOR where the type of the operands doesn't match the vector element type (this is supposed to be illegal), while LegalizeTypes correctly constructs a BUILD_VECTOR where the operand type is equal to the vector element type, but then the PPC custom code doesn't handle this optimally. Two solutio...

...rPC 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 building a v2f64 vector out of two operands. I tried writing this pattern as: def : Pat<(v2f64 (build_vector F8RC:$A, F8RC:$B)), (FSMFP (INSERT_SUBREG (v2f64 (IMPLICIT_DEF)), F8RC:$A, sub_64), (INSERT_SUBREG (v2f64 (IMPLICIT_DEF)), F8...

...ould use the canonical IR form for splats of scalable vector types (insert element into lane 0 of an undef vector, shuffle that with another undef vector of the same type and a zeroinitializer mask). We do run into a problem for lowering to SelectionDAG however, since the canonical form there is a BUILD_VECTOR with all elements being the same. This obviously doesn't work if we don't know how many elements there are. We have a couple of solutions and would like to know which the community prefers. 1) Add a new SPLAT_VECTOR ISD node. This was part of our overall RFC from 2016 and is the solution t...

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 fix it by truncating the elements back to i8 in ExpandBUILD_VECTOR. Does this seem like the right approach? I ask because...

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 fix it by truncating the > elements back to i8 in ExpandBUILD_VECTOR. Does this seem like the > right appro...

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful not the use the operand type (i32) when it really wants...

...pecific isel lowering will be eliminated during DAG combine. > > Let me know if there is another, better supported, approach for this kind of problems. > > ** Motivating Example ** > The motivating example comes form the lowering of vector code on armv7. > More specifically, the build_vector node is lowered to a target specific ARMISD::build_vector where all the parameters are bitcasted to floating point types. > > This works well, unless the inserted bitcasts survive until instruction selection. In that case, they incur moves between integer unit and floating point unit that ma...