search for: eltvt

...t check if it is legal or not. But the comment says ‘try to widen vector elements until a legal type is found’. Also, there is a minor issue with the comment <3 x float> to <4 x float>, where the float vectors won’t even enter this block of code, since we check the element Vector type (EltVT) to be integer. The patch breaks a whole lot of test-cases, so it is obviously not the ideal solution. It simply reflects what the comment says. diff --git a/include/llvm/Target/TargetLowering.h b/include/llvm/Target/TargetLowering.h index c3fa3cc..181f951 100644 --- a/include/llvm/Target/TargetL...

...ess. We first widen the vector to a power of two, and after that we split, promote, scalarize, etc. > > Also, there is a minor issue with the comment <3 x float> to <4 x float>, where the float vectors won’t even enter this block of code, since we check the element Vector type (EltVT) to be integer. The code is okay. The comment should be changed to something with integers. > > The patch breaks a whole lot of test-cases, so it is obviously not the ideal solution. It simply reflects what the comment says. > > diff --git a/include/llvm/Target/TargetLowering.h b/i...

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

...g on each element individually. +SDValue VectorLegalizer::UnrollVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't unroll a vector with multiple results!"); + unsigned NE = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + + SmallVector<SDValue, 8> Scalars; + SmallVector<SDValue, 4> Operands(Op.getNumOperands()); + for (unsigned i = 0; i != NE; ++i) { + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + SDValue Operand = Op....

...->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); > } I assume that we need the opposite - if (.. < 8) getExtLoad // VT should be MVT::i8, MemVT should be MVT::i1 else getLoad - Elena From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Monday, September 18, 2017 13:40 To: Demikhovsky, Elena <elena.demikhovs...

...g on each element individually. +SDValue VectorLegalizer::UnrollVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't unroll a vector with multiple results!"); + unsigned NE = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + + SmallVector<SDValue, 8> Scalars; + SmallVector<SDValue, 4> Operands(Op.getNumOperands()); + for (unsigned i = 0; i != NE; ++i) { + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + SDValue Operand = Op....

...roughly. if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); } else { return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); } How do you think about it? Thanks, JinGu Kang On 15/09/2017 18:42, Demikhovsky, Elena wrote: extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com<mailto...

> extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...return DAG.getNode(ISD::FSUB, Op.getDebugLoc(), Op.getValueType(), + Zero, Op.getOperand(0)); + } + return UnrollVectorOp(Op); +} + +SDValue VectorLegalizer::UnrollVSETCC(SDValue Op) { + MVT VT = Op.getValueType(); + unsigned NumElems = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + SDValue LHS = Op.getOperand(0), RHS = Op.getOperand(1), CC = Op.getOperand(2); + MVT TmpEltVT = LHS.getValueType().getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + SmallVector<SDValue, 8> Ops(NumElems); + for (unsigned i = 0; i < NumElems; ++i...

...ed-but-set-variable] /home/greened/src/llvm-30-rc3/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp: In member function ‘llvm::SDValue {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDValue)’: /home/greened/src/llvm-30-rc3/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1652:19: warning: variable ‘EltVT’ set but not used [-Wunused-but-set-variable] /home/greened/src/llvm-30-rc3/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1632:15: warning: variable ‘WideScalarVT’ set but not used [-Wunused-but-set-variable] /home/greened/src/llvm-30-rc3/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp: In member function...

On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: > We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: > >        http://llvm.org/pre-releases/3.0/rc3/ > > for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your

Good day, LLVMers! We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: http://llvm.org/pre-releases/3.0/rc3/ for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your projects, and let us know if you find any regressions from the 2.9 release. Please keep

...d for common code to preserve the scalable flag we extend the helper functions within MVT/EVT classes to cover more cases. For example: ```cpp /// Return a VT for a vector type whose attributes match ourselves /// but with an element type chosen by the caller. EVT changeVectorElementType(EVT EltVT)` ``` # Instructions The majority of instructions work seamlessly when applied to scalable vector types. However, on occasion assumptions are made that allow vectorization logic to be reduced directly to constants completely bypassing the IR (e.g. when the element count is known). These assumptio...