similar to: [LLVMdev] type legalizer promoting BUILD_VECTORs

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

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

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

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

Hi Krzysztof, Sure, please see below. DAG.dump.() before and after, annotated with what I believe the DAG means. I've spent some time debugging the method but it's proving difficult to determine where the logic is misfiring. Disabling the entire combine causes a lot of failing x86-64 tests - I may have to learn an upstream vector ISA to make progress on this. Thank you >From your

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

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

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

Hi all, I have a backend for an in house architecture, and would like to start working on support for vector datatypes and intrinsics. As I starter I would like to have vector code scalarized, as is done, e.g., for the Mips backend. However, I cannot find a way to force the instruction selector or type legalizer to scalarize the vectors (i.e., vector types and vector ops). Can anyone help me out?

v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where

Hi, On 01/22/2016 05:02 PM, Tom Stellard wrote: > On Fri, Jan 22, 2016 at 01:58:49PM +0100, Mikael Holmén via llvm-dev wrote: >> Hi, >> >> I'm a litle bit puzzled by the TargetLowering::LowerOperation function, >> and what different callers of this function assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best

Hi all, I am working on a target that has support for v4i16 vectors, and no support for v4i8 / v8i8 / v8i16 V4i8 is promoted to v4i16 which is nice V8i16 is split to 2 x v4i16 which is nice as well Now v8i8 is scalarized, which is not so nice. Ideally I would like v8i8 to be first promoted to v8i16 then split to 2xv4i16 (or split to 2xV4i8 then promoted to 2xv4i16) Is there a way to achieve

Hi All, I have some doubt in LLVM Type Legalizer. How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 type is not legal for our target) Following assertion in function ExpandIntegerOperand (file LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 &&

Hi, I'm working on an LLVM backend for an architecture which does not natively support half-word loads. I'm having trouble getting LLVM to promote i16 to i32 loads for me - should I expect LLVM to be able to do this, are do I have to write a custom lowerer? This post (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019929.html) gave me the impression that it should be possible,

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