similar to: [LLVMdev] canonicalizing types for vector operations

On Aug 17, 2009, at 7:15 AM, Bob Wilson wrote: > I committed a change to fix pr4731 yesterday but after thinking about > it some more, I'd like to get other opinions about this. Chris and I > talked last week about the need to canonicalize the types used for > Neon vector shuffles so that they get CSEd. I guess this was an issue > that came up for SSE. > > For pr4731, I

On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote: > I really do think that bitcast is the right way to go here. I ran > into a couple of similar problems when bringing up the altivec port. > For example, at one time we'd get "all zero vectors" of different > MVTs, which would not be CSEd. > > The fix for this was to be really disciplined about what types to make

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 Aug 8, 2009, at 11:47 PM, Bob Wilson wrote: > The ARM Neon load, store and shuffle operations that I've been > implementing recently with LLVM intrinsics do not care about the > distinction between vectors with i32 and f32 elements -- only the size > matters. But, because we have only MVT::fAny and MVT::iAny types, > I've been having to define separate intrinsics for

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

On 03/09/2017 12:57 PM, Krzysztof Parzyszek wrote: > On 3/9/2017 12:47 PM, Hal Finkel wrote: >> >> On 03/09/2017 12:28 PM, Krzysztof Parzyszek via llvm-dev wrote: >>> We could add intrinsics to extract/insert a bitfield, which would >>> simplify a lot of that bitwise logic. >> >> But then you need to teach a bunch of places about how to simply them,

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>

The ARM Neon load, store and shuffle operations that I've been implementing recently with LLVM intrinsics do not care about the distinction between vectors with i32 and f32 elements -- only the size matters. But, because we have only MVT::fAny and MVT::iAny types, I've been having to define separate intrinsics for the operations with floating-point vector elements. It

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>

Hi, I received an internal test case from a game team (it wasn't about this in particular), and I was wondering if there was maybe an opportunity to canonicalize a particular code pattern: %inputi = bitcast <4 x float> %input to <4 x i32> %row0i = and <4 x i32> %inputi, <i32 -1, i32 0, i32 0, i32 0> %row0 = bitcast <4 x i32> %row0i to <4 x float>

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

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

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 Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > > > > On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev

On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> >> 2016-12-23 22:17 GMT+01:00 David

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

On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> wrote: On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: 2016-12-23

2016-12-24 9:39 GMT+01:00 Chandler Carruth <chandlerc at google.com>: > On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > > On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

On Fri, 2 May 2008, Jay Foad wrote: > I wrote some code that fell over when it encountered this ConstantExpr: > i32 add (i32 24, i32 ptrtoint ([20 x %"struct.stlpmtx_std::string"]* > @_ZN12BulletMLNode11name2stringE to i32))) > > because it expected the LHS of the add to be another ConstantExpr. (This is > the first time that bit of code has fallen over, despite having

BTW are we planning to also remove gep 0 after we would have typeless pointers? I saw the David's presentation year ago but I am not sure if it was mentioned. If it would be removed, then does it mean that SROA would still need some new code to handle it (assuming it doesn't handle bitcasts right now) Here is the patch solving my issue https://reviews.llvm.org/D28126 2016-12-25 13:40