search for: extract_subvectors

Hello, Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 =

Hi Hal, On 05/03/13 18:50, Hal Finkel wrote: > Hello, > > Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: > > Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] > > Scalarize node result 0: 0x2348220: v1f32 = extract_subvector

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

...oks like the main complexity comes from the fact that the DAG which emerges from SelectionDAGBuilder::visitShuffleVector is often rather low-level. A case could probably be made for keeping more information around in the DAG, but that would require cooperation among all the backends. For now, both EXTRACT_SUBVECTORs and BUILD_VECTORs seem to be handled on ARM mainly by resorting to the stack, which often leads to rather bad code. EXTRACT_SUBVECTOR in particular should just involve ignoring one of the registers. I've put together a couple of patches to improve matters: http://www.maths.ed.ac.uk/~s0677366/...

I ran into some odd code being generated today and I came across something that doesn't look quite right. In SelectionDAGBuilder::visitShuffleVector there's some code to see if we can convert the shuffle to an EXTRACT_SUBVECTOR. After computing min/max values of the mask for each operand, there's a look that looks at the ranges and determines whether an EXTRACT_SUBVECTOR can be used:

Is there an established way of disabling a DAG combine on a per target basis, where it appears to be detrimental to the generated code? Writing if (!mytarget) in DAGCombiner.cpp works but tends to be erased by git merge and generally doesn't look ideal. Writing the inverse transform in target specific code doesn't work in this instance and in general creates an infinite loop. Guidance

Hi, I am a little unsure about the semantics of the ShuffleKind SK_ExtractSubvector. It seems a subvector is to be extracted, starting from a given index of a given subtype. First of all, if index 0 is passed, I suppose this would mean a noop? But what about calls like the one made of LoopVectorizer for Instruction::PHI in getInstructionCost(): return

On Mon, 11 Jun 2007, Dan Gohman wrote: > Here's a quick update on where I'm at with the pre-legalize vector changes > I'm working on. I hope to have an updated patch ready to a few days, assuming > I don't get too busy with other projects going on. Here are some of the issues > I've come across so far. Great! I'm going to reorder your email a bit to suit my

Hello, Here's a quick update on where I'm at with the pre-legalize vector changes I'm working on. I hope to have an updated patch ready to a few days, assuming I don't get too busy with other projects going on. Here are some of the issues I've come across so far. Putting the table for extended ValueTypes in SelectionDAG seems quite involved. There are a lot of places that use

On Wed, Dec 2, 2009 at 3:46 PM, David Greene <dag at cray.com> wrote: > The AVX saga continues. > > I am attempting to write a pattern for VEXTRACTF128 but am having some > problems.  My attempt looks something like this: > > defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, >                      MRMDestMem, "extractf128", undef,

Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT,

The AVX saga continues. I am attempting to write a pattern for VEXTRACTF128 but am having some problems. My attempt looks something like this: defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, MRMDestMem, "extractf128", undef, X86f32, X86i32i8, // rr [(set VR128:$dst,

On 2017-01-20 14:31, Hal Finkel wrote: > > On 01/20/2017 06:11 AM, Jonas Paulsson via llvm-dev wrote: >> Hi, >> >> I wonder why getScalarizationOverhead() does not take into account >> the number of operands of the instruction? This should influence the >> number of extracts needed, so instead of >> >> Scalarization cost = NumEls * (insert +

On May 20, 2009, at 9:14 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 5:26 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> 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

On Mon, Sep 29, 2008 at 8:11 PM, Mon Ping Wang <wangmp at apple.com> wrote: > The problem with generating insert and extracts is that we can generate poor > code > %tmp16 = extractelement <4 x float> %f4b, i32 0 > %f8a = insertelement <8 x float> %f8a, float %tmp16, i32 0 > %tmp18 = extractelement <4 x float> %f4b, i32 1 > %f8c

Hi all, After the previous RFC[1], there were multiple discussions on the ML and in person at the DevMtg. I will summarize the options discussed and propose a path forward. =========================== Options =========================== A. Extend VectorType to be multidimensional B. Flatten matrices into the current VectorType. Matrix shape and layout information is passed to matrix

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

Hi, We've been working for the last two years on support for ARM's Scalable Vector Extension in LLVM, and we'd like to upstream our work. We've had to make several design decisions without community input, and would like to discuss the major changes we've made. To help with the discussions, I've attached a technical document (also in plain text below) to describe the

Hello, I have a kernel that's swizzling a vector inside a loop. The vector was created before the loop. The first node in the dag is an extract subvector which calls into SplitVectorOp. The issue is that the node passed to it comes from a CopyFromReg and SplitVectorOp doesn't know what to do. Is there a reason why SplitVectorOp doesn't handle CopyFromReg nodes? If not, can I submit a

Hi Javier, > I have a kernel that's swizzling a vector inside a loop. The vector was > created before the loop. The first node in the dag is an extract subvector > which calls into SplitVectorOp. The issue is that the node passed to it > comes from a CopyFromReg and SplitVectorOp doesn't know what to do. Is > there a reason why SplitVectorOp doesn't handle CopyFromReg