search for: shuffling

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

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Friday, February 7, 2020 3:00 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 Feb 7, 2020, at 12:39 PM, Eli Friedman

...t;andrea.dibiagio at gmail.com > wrote: > Hi Chandler, > > On Fri, Jan 23, 2015 at 8:15 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > Greetings LLVM hackers and x86 vector shufflers! > > > > I would like to flip on another chunk of the new vector shuffling, > > specifically the logic to mark ~all shuffles as "legal". > > > > This can be tested today with the flag > > "-x86-experimental-vector-shuffle-legality". I would essentially like to > > make this the default (by removing the "false" pa...

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>

Greetings LLVM hackers and x86 vector shufflers! I would like to flip on another chunk of the new vector shuffling, specifically the logic to mark ~all shuffles as "legal". This can be tested today with the flag "-x86-experimental-vector-shuffle-legality". I would essentially like to make this the default (by removing the "false" path). Doing this will allow me to completely delet...

Hi all, Attached herewith is a fairly simple LLVM file (shuffle.ll) with lots of vector shuffles. When I use llc with -O3 -mcpu=core-avx2 the first shuffle sequence containing types of 128 wide gets reduced a single shuffle, where as the second shuffle sequence containing types of 256 wide doesn't get reduced to a single shuffle instruction in the resulting X86 code (Shuffle.s attached).

On Mar 27, 2011, at 1:16 PM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: > >>> We would still keep the existing pre-table-driven-isel passes so we'd >>> still have a chance to do some cleanup before the main table-driven >>> isel. >>> >>> Obviously a lot of details have to be worked out. >> >>

Chris Lattner <clattner at apple.com> writes: >> We would still keep the existing pre-table-driven-isel passes so we'd >> still have a chance to do some cleanup before the main table-driven >> isel. >> >> Obviously a lot of details have to be worked out. > > I'm not seeing how this is useful for shuffles. Since tblgen doesn't > generate

Wow. Somehow, I forgot about vbroadcast and vpbroadcast. =[ Sorry about that. I'll fix those. On Fri, Sep 26, 2014 at 3:39 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com > wrote: > Hi Chandler, > > Here is another test. > > When looking at the AVX codegen, I noticed that, when using the new > shuffle lowering, we no longer emit a single vbroadcastss in the case

Hello, I was wondering if anyone can think of a straightforward way (without loops) to do the following shuffling: Let's imagine a vector: c(1,1,1,2,2,3,3,3) I would like to derive shuffled vectors __where the same digits are never separated__, although they can be at both ends (periodicity). So the following shuffled vectors are possible: c(2,2,1,1,1,3,3,3) c(2,1,1,1,3,3,3,2) c(3,3,3,1,1,1,2,2) c(3,1,...

On Thursday 17 December 2009 18:04, Anton Korobeynikov wrote: > Hello, David > > > Can you expand on this with an example?  There seems to be an awful lot > > of shuffle patterns and predicates in PPCInstrAltivec.td.  What do you > > mean by, "Canonicalize to byte ops?"  Can you walk me through how that > > works with Altivec? > > The basic idea is

Hi, I'me trying to write a function that will shuffle a vector. At the moment I'm baically making a vector of randomized indices and then making a new vector from the original one using these random indices. However, is there an alternative (more elegant) method to do this? I tried help.search('shuffle') but it does'nt return anything relevant. Thanks,

On Dec 17, 2009, at 4:12 PM, David Greene wrote: > On Thursday 17 December 2009 18:04, Anton Korobeynikov wrote: >> Hello, David >> >>> Can you expand on this with an example? There seems to be an awful lot >>> of shuffle patterns and predicates in PPCInstrAltivec.td. What do you >>> mean by, "Canonicalize to byte ops?" Can you walk me

Hi, I need to permute the rows of a matrix, where each row is independently rearranged. A simple solution is this: shuffled <- datamatrix <- matrix(1:24, ncol = 4) for (i in 1:nrow(datamatrix)) { shuffled[i, ] <- sample(datamatrix[i, ]) } > datamatrix [,1] [,2] [,3] [,4] [1,] 1 7 13 19 [2,] 2 8 14 20 [3,] 3 9 15 21 [4,] 4 10 16 22 [5,]

On Tue, Sep 23, 2014 at 2:35 PM, Simon Pilgrim <llvm-dev at redking.me.uk> wrote: > If you don’t want to spend time on this, I’d be happy to create a > candidate patch for review? I’ve been unclear if you were taking patches > for your shuffle work prior to it becoming the default. While I'm happy to work on it, I'm even more happy to have patches. =D -------------- next

Hi, building 'check-all' on any of my machines running OS X 10.10 usually fails because a few tests fail due to some processes being killed by the kernel (there's always "Killed: 9" somewhere in lit's error output). Everything's fine on 10.9. How do folks deal with this? Don't use 10.10 for building llvm? Is there some tweakable to tell the kernel "please

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

On Thursday 17 December 2009 17:16, Nate Begeman wrote: > David, this is probably the wrong approach, based on the accreted awfulness > of the X86 shuffle lowering code, Ha! I have no issue believing this statement. :) > The correct approach is probably a rewrite based around what > AltiVec does: Canonicalize to byte ops, and write all the patterns once > rather than having to

R programming question, not machine learning, although that's the content. Apologies to all for whom the following code is eye-burning. I am using foreach() to run a simulation on a randomForest model (actually conditional randomForest ... "party" package). The simulation is in two dimensions. examining how "mtry" and "ntrees" are related in terms of predictive

On Tue, Sep 9, 2014 at 11:39 PM, Chandler Carruth <chandlerc at google.com> wrote: > Awesome, thanks for all the information! > > See below: > > On Tue, Sep 9, 2014 at 6:13 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> > wrote: >> >> You have already mentioned how the new shuffle lowering is missing >> some features; for example, you explicitly