similar to: R - Vectorization and Functional Programming Constructs

On Mon, 3 Jun 2019 at 20:00, Francesco Petrogalli via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > The original intend of this thread is to "Expose user provided vector > function for auto-vectorization.” > > I originally proposed to use OpenMP `declare variant` for the sake of > using something that is defined by a standard. The RFC itself is not

On 13 April 2018 at 16:52, Robin Kruppe <robin.kruppe at gmail.com> wrote: > On 13 April 2018 at 14:37, Graham Hunter <Graham.Hunter at arm.com> wrote: > >> Hi, >> >> Nice to see another group tackling length agnostic vectorization :) >> >> I'm still reading through all the details, but I do have one initial >> question related to the

Hi, Comments below On 13 April 2018 at 16:52, Robin Kruppe <robin.kruppe at gmail.com<mailto:robin.kruppe at gmail.com>> wrote: On 13 April 2018 at 14:37, Graham Hunter <Graham.Hunter at arm.com<mailto:Graham.Hunter at arm.com>> wrote: Hi, Nice to see another group tackling length agnostic vectorization :) I'm still reading through all the details, but I do have one

I'm just going to add Kristof here since ARM is looking to add SVE here and this overlaps quite a bit with their goals. -eric On Wed, Apr 11, 2018 at 2:45 AM Robin Kruppe via llvm-dev < llvm-dev at lists.llvm.org> wrote: > RISC-V is an open and free instruction set architecture (ISA) used in > numerous domains in industry and research. The vector extension (short: >

Hi, i am the main author of RV, the Region Vectorizer (github.com/cdl-saarland/rv). I want to share our standpoint as potential users of the proposed vector-length agnostic IR (RISC-V, ARM SVE). -- support for `llvm.experimental.vector.reduce.*` intrinsics -- RV relies heavily on predicate reductions (`or` and `and` reduction) to tame divergent loops and provide a vector-length agnostic

RISC-V is an open and free instruction set architecture (ISA) used in numerous domains in industry and research. The vector extension (short: 'V') supplements the basic ISA with support for data parallel computations. This RFC sketches a strategy for targeting this instruction set extension in LLVM. Some but not all of what is proposed here has already been implemented out of tree. It is

Hi All, The original intend of this thread is to "Expose user provided vector function for auto-vectorization.” I originally proposed to use OpenMP `declare variant` for the sake of using something that is defined by a standard. The RFC itself is not about fully implementing the `declare variant` directive. In fact, given the amount of complication it is bringing, I would like to move the

Add the NVreg_RegistryDwords command line parameter, which allows specifying additional registry keys to be sent to GSP-RM. This allows additional configuration, debugging, and experimentation with GSP-RM, which uses these keys to alter its behavior. Note that these keys are passed as-is to GSP-RM, and Nouveau does not parse them. This is in contrast to the Nvidia driver, which may parse some

Assuming your polyline is defined by two vectors, one for the x coordinates, one for the y coordinates, you can try the following library(NISTunits) polyangles <- function(xV,yV) { stopifnot( (length(xV)==length(yV)) && (length(xV) >= 3)) v <- function(i) { c( xV[i]-xV[i-1], yV[i]-yV[i-1])} vlen <- function(v) { sqrt(sum(v*v)) } lV <- rep(NA_real_,length(xV)) for

On Wed, 2 Oct 2019 at 05:09, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote: > > My general feeling on this then is that both RVV and SV should avoid using > vscale. > > In the case of RVV, MVL is a hardware defined constant that is never > *intended* to be known by applications. There's no published detection > mechanism. Loops are supposed to be designed

I like to use complex numbers for 2-dimensional geometry. E.g., > polyAngles2 function (xV, yV) { stopifnot((length(xV) == length(yV)) && (length(xV) >= 3)) z <- complex(re = xV, im = yV) c(NA, diff(Arg(diff(z))), NA) # radians, positive is counter-clockwise } > x <- c(0:3) > y <- c(0,0,1,1) > polyAngles2(x,y) / pi * 180 [1] NA 45 -45 NA Bill

I've been in discussion with a colleague who had to reduce (!) SO_SNDBUF to get decent performance, and so wrote this little tool. It tells you the system default for most of the settable socket options. It can't do linger, as the value is a struct instead of an int, but that's probably uninteresting to Samba folks. Run this to see what you'd have if you didn't set any

The kernel returns xattr names in a slightly peculiar format. We parsed this format several times in the code. Refactoring this parsing so we only do it in one place. --- daemon/xattr.c | 126 ++++++++++++++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 48 deletions(-) diff --git a/daemon/xattr.c b/daemon/xattr.c index 5c9f064ce..482df9af0 100644 --- a/daemon/xattr.c +++

The kernel returns xattr names in a slightly peculiar format. We parsed this format several times in the code. Refactor this parsing so we only do it in one place. --- daemon/xattr.c | 123 ++++++++++++++++++++++++++++++------------------- 1 file changed, 75 insertions(+), 48 deletions(-) diff --git a/daemon/xattr.c b/daemon/xattr.c index 5c9f064ce..761f6074b 100644 --- a/daemon/xattr.c +++

I think you and I are talking two different things. As far as Intel’s vector function ABI is concerned, unless the programmer specifically says otherwise, given an OpenMP declare simd function, compiler will deduce the VF from HW vector register size and other function signatures. Of course, there can be different vector function ABIs for different targets. Intel compiler cost model uses vector

v1 here: https://www.redhat.com/archives/libguestfs/2020-March/msg00099.html This one fixes most of the points picked up in review, and does not strdup the strings which should keep down memory usage if that is a concern. Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=1811539 Commands including virt-diff which read extended attributes will sometimes fail on NTFS filesystems that are using system compressed. The reason is complex, see comment 5 of the bug linked above. This patch filters out the troublesome xattr. For justification, see the comment I added in patch 3. Patch 1 & 2 are refactoring. I was on the

Hi Francesco, On 06/03, Francesco Petrogalli wrote: > > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote: > > as a candidate future user of the proposed extension, I think I like the simplified proposal better than the original RFC. > > > > The only part of the syntax that I would find not very much user-friendly is having to mangle the

On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote: > On 2/4/19 9:18 PM, Robin Kruppe wrote: > > > > On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Simon Moll <moll at cs.uni-saarland.de> writes: >> >> > You are referring to the sub-vector sizes, if i am

Hello, I'm attempting to access a specific number of sub diagonals in a MATRIX and have been accustomed to using spdiags in MATLAB or Octave. I've got a solution pieced together using for loops and it works though isn't vectorized and liable to run very slow for large matrices. As an example: A = 1 2 3 4 5 9 8 7 6 5 4 5 6 7 8 5 4 3 2 1 8 7 6 0 1 The subdiagonals are: 9,5,3,0 4,4,6