search for: build_vectors

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

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 >

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 allowed to be larger than the element type, in

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

..., in SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op): case ISD::BUILD_VECTOR: // A weird case: legalization for BUILD_VECTOR never legalizes the // operands! // FIXME: This really sucks... changing it isn't semantically incorrect, // but it massively pessimizes the code for floating-point BUILD_VECTORs // because ConstantFP operands get legalized into constant pool loads // before the BUILD_VECTOR code can see them. It doesn't usually bite, // though, because BUILD_VECTORS usually get lowered into other nodes // which get legalized properly. SimpleFinishLegalizing = false; break; and then:...

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

...lize::LegalizeOp(SDValue Op): > > case ISD::BUILD_VECTOR: > // A weird case: legalization for BUILD_VECTOR never legalizes the > // operands! > // FIXME: This really sucks... changing it isn't semantically incorrect, > // but it massively pessimizes the code for floating-point BUILD_VECTORs > // because ConstantFP operands get legalized into constant pool loads > // before the BUILD_VECTOR code can see them. It doesn't usually bite, > // though, because BUILD_VECTORS usually get lowered into other nodes > // which get legalized properly. > SimpleFinishLegalizing =...

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

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

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 >

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

(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 vec...

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 cleaner design, it also supports code generation for arbitrary precision integers such as

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

Hi, During the discussion on introducing scalable vectors we established that we could 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

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

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

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

On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during target