similar to: IR canonicalization: vector select or shufflevector?

I have a slight preference towards shufflevector, because it makes sequences of shuffles, where only some of the shuffles can be converted into selects (because the input and output vector sizes of the others don't match) simpler to reason about. I'm not sure this is a particularly good reason, though. On Mon, Aug 29, 2016 at 8:19 AM, Philip Reames via llvm-dev < llvm-dev at

x86 has also put a lot of effort into shuffle lowering...so much so that it is its own life-form and brings most online codeviewer apps to their knees when you try to open X86ISelLowering.cpp. :) Given that: 1. There are at least 2 targets that lean towards shuffle (Martin's comment + x86 uses lowerVSELECTtoVectorShuffle() for all cases like the example posted here) 2. Size-changing shuffles

It's time for another round of "What is the canonical IR?" Credit for this episode to Zvi and PR31551. :) https://llvm.org/bugs/show_bug.cgi?id=31551 define <4 x i16> @shuffle(<16 x i16> %x) { %shuf = shufflevector <16 x i16> %x, <16 x i16> undef, <4 x i32> <i32 0, i32 4, i32 8, i32 12> ret <4 x i16> %shuf } define <4 x i16>

On 1/12/2017 9:04 AM, Sanjay Patel via llvm-dev wrote: > It's time for another round of "What is the canonical IR?" > > Credit for this episode to Zvi and PR31551. :) > https://llvm.org/bugs/show_bug.cgi?id=31551 > define <4 x i16> @shuffle(<16 x i16> %x) { > %shuf = shufflevector <16 x i16> %x, <16 x i16> undef, <4 x i32> <i32 0,

On Thu, Jan 12, 2017 at 11:06 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/12/2017 9:04 AM, Sanjay Patel via llvm-dev wrote: > > It's time for another round of "What is the canonical IR?" > > Credit for this episode to Zvi and PR31551. :) > https://llvm.org/bugs/show_bug.cgi?id=31551 > > define <4 x i16> @shuffle(<16 x i16>

Right - I think that case looks like this for little endian: define <2 x i32> @zextshuffle(<2 x i16> %x) { %zext_shuffle = shufflevector <2 x i16> %x, <2 x i16> zeroinitializer, <4 x i32> <i32 0, i32 2, i32 1, i32 2> %bc = bitcast <4 x i16> %zext_shuffle to <2 x i32> ret <2 x i32> %bc } define <2 x i32> @zextvec(<2 x i16>

As Sanjay noted in D31426<https://reviews.llvm.org/D31426#712701>, InstructionSimplify is missing the following simplification: This function: define <4 x i32> @splat_operand(<4 x i32> %x) { %splat = shufflevector <4 x i32> %x, <4 x i32> undef, <4 x i32> zeroinitializer %shuf = shufflevector <4 x i32> %splat, <4 x i32> undef, <4 x i32>

We use InstCombiner::ShouldChangeType() to prevent transforms to illegal integer types, but I'm not sure how that would apply to vector types. Ie, let's say v256 is a legal type in your example. DataLayout doesn't appear to specify what configurations of a 256-bit vector are legal, so I don't think we can currently use that to say v2i128 should be treated differently than v16i16.

On Thu, Jan 19, 2017 at 9:17 AM, Rackover, Zvi <zvi.rackover at intel.com> wrote: > Hi Sanjay, > > > > I agree we should also discuss **if** this canonicalization is beneficial. > > For starters, do we have a concrete case where we would benefit from > canonicalizing shuffles <-> truncates in LLVM IR? > > IMO, we should not count benefits for codegen

Sanjay, I'm looking at some missed optimizations caused by D70246. Here's a test case: define <4 x float> @f(i32 %t32, <4 x float>* %t24) { .entry: %t43 = insertelement <3 x i32> undef, i32 %t32, i32 2 %t44 = bitcast <3 x i32> %t43 to <3 x float> %t45 = shufflevector <3 x float> %t44, <3 x float> undef, <4 x i32> <i32 0, i32 undef,

Hi, I am trying to understand LLVM vectorization implementation and was looking into both loop and SLP vectorization. test case 1: *int foo(int *a) {int sum = 0,i;for(i=0; i<16; i++) sum += a[i];return sum;}* This code is vectorized by loop vectorizer where we calculate scalar loop cost as 4 and vector loop cost as 2. Since vector loop cost is less and above reduction is legal to

Hi Nadav, Thanks for the quick reply !! Ok, so as of now we are lacking capability to handle flat large reductions. I did go through function vectorizeChainsInBlock() (line number 2862). In this function, we try to vectorize if we have phi nodes in the IR (several if's check for phi nodes) i.e we try to construct tree that starts at chains. Any pointers on how to join multiple trees? I

On Thu, 30 Jan 2020 at 08:22, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > This fixed list of shuffles makes me uncomfortable, and I wonder if > there isn't a much simpler solution to the problem. Specifically, > allow the IR form: > > %result = shufflevector <vscale x n x TY> %v1, <vscale x n x TY> %v2, > <m x i32> <mask>

Thanks, Sanjay, that makes sense. The opportunity for improving instcombining splat sounds promising. Another question about shuffle simplification. This is a testcase from test/Transforms/InstCombine/vec_shuffle.ll: define <4 x i32> @test10(<4 x i32> %tmp5) nounwind { %tmp6 = shufflevector <4 x i32> %tmp5, <4 x i32> undef, <4 x i32> <i32 1, i32 undef, i32

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

On 11/27/19 2:10 AM, Eli Friedman via llvm-dev wrote: The shuffle mask of a shufflevector is special: it's required to be a constant in a specific form. From LangRef: "The shuffle mask operand is required to be a constant vector with either constant integer or undef values." So really, we can resolve this any way we want; "undef" in this context doesn't have to mean

Currently, for scalable vectors, only splat shuffles are allowed; we're considering allowing more different kinds of shuffles. The issue is, essentially, that a shuffle mask is a simple list of integers, and that isn't enough to express a scalable operation. For example, concatenating two fixed-length vectors currently looks like this: shufflevector <2 x i32> %v1, <2 x i32>

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Wednesday, February 5, 2020 4:02 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC] Extending shufflevector for vscale vectors > (SVE etc.) > > On Jan 29, 2020, at 4:48 PM, Eli Friedman via

Andreas, On Thu, Aug 24, 2017 at 03:37:07PM +0200, awl1 via samba wrote: > Before I follow your advice to move this whole issue/topic to the > samba-technical alias and start over there with a clean description of the > scenario and the findings, I have two simple questions: > > 1) I plan to use a new, reproducible test scenario with 2000 random small > files with a file length