search for: shuffl

> -----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 llvm-dev <llvm- > dev at lists.llvm.org> wrote: > > > > Currently, for scalable vectors, only splat shuffles are allowed; we're > considering allowing more different kinds o...

> -----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 <efriedma at quicinc.com> wrote: > >> > >> Hi Eli, > >> > >> Did you consider a design point between these two extremes? You could > >> introduce on...

I ran the benchmarking subset of test-suite on a btver2 machine and optimizing for btver2 (so enabling AVX codegen). I don't see anything outside of the noise with x86-experimental-vector-shuffle-legality=1. On Fri, Jan 23, 2015 at 5:19 AM, Andrea Di Biagio <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! > >...

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: s...

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

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

...ll 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 table based matching for *any* shuffles, all of the matching >> code would end up as C++ code in X86ISelDagToDag, which would give us >> all of the problems we had before by moving to X86ISD nodes. > > bool X86TargetLowering::isShuff...

...s: >> 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 table based matching for *any* shuffles, all of the matching > code would end up as C++ code in X86ISelDagToDag, which would give us > all of the problems we had before by moving to X86ISD nodes. Actually, it would be matching code in X86ISelLowerin...

...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 > where the shuffle performs a splat of a scalar float loaded from > memory. > > For example: > (with -mcpu=corei7-avx -x86-experimental-vector-shuffle-lowering) > vmovss (%rdi), %xmm0 > vpermilps $0, %xmm0, %...

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

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 quite simple - lower everything to vNi8 and write > all the patterns using only these...

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

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 through how that >>> works with Altivec? >> >> The basic idea is quite simple - lower everything to vNi8 and write >> all the pattern...

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,] 5 11 17 23 [6,]...

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 part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/53d37d9a/attachment.html>

...d: 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 don't kill my processes"? Here's an example from just now: FAIL: LLVM :: MC/X86/shuffle-comments.s (18589 of 28139) ******************** TEST 'LLVM :: MC/X86/shuffle-comments.s' FAILED ******************** Script: -- /Users/thakis/src/chromefetch/src/third_party/llvm-bootstrap/./bin/llvm-mc /Volumes/MacintoshHD2/src/chromefetch/src/third_party/llvm/test/MC/X86/shuffle-comment...

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

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 look for 6 different variants of the same pattern. Can you...

...) : task 2 failed - "argument "x" is missing, with no default" as if it couldn't see the arguments. Long segment of actual code below. Thank you for your time and patience. Ross <code> bottomloop<-function(i=i, mtry=mtry, rownumber=rownumber, ntrees=ntrees, shuffled=shuffled) { require(party) require(epiR) test<-rownumber[[i]] train<-shuffled[shuffled!=test] cv.train <- ml.frame[train,] cv.evaluate <- ml.frame[test,] cv.model <- cforest(as.factor(remitter)~., data=cv.train, control=cforest_control(mtry=mtry, ntree=ntrees, mincrit...

...t 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 said that we currently lack >> of SSE4.1 blend support. Unfortunately, this seems to be one of the >> main reasons for the slowdown we are seeing. >> >> Here is a list of what we found so far that we th...