similar to: Which pass should be propagating memory copies

Keno, Perhaps you can view the problem to be the memcpys themselves, We humans can look at the memcpys and see loads and stores but to almost all optimizer passes they aren’t what it is looking for, They instead see function calls which they mostly don’t touch, If these memcpys were inlined into plain old loads and stores The redundant loads and stores should be deleted by existing opts

Hi all, A quick note just to let people know that as of this past Friday my go at this work has been fully landed. It ended up being a back-burner item, so it took longer than I would have liked to get completed. None the less, the changes made were: 1) The IRBuilders in LLVM, Clang, and Polly were all updated to create only the new form of the memory intrinsics. 2) All LLVM passes to understand

Good day all, I’ve spent a few days resurrecting the circa-2015 work on removing the explicit alignment argument (4th arg) from the @llvm.memcpy/memmove/memset intrinsics in favour of using the alignment attribute on the pointer args of calls to the intrinsic. This work was first proposed back in August 2015 by Lang Hames: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html (item

Hi Daniel, a quick question (and kind-of a follow-up to <https://lists.llvm.org/pipermail/llvm-dev/2017-July/115665.html>): Do the pointers have to be aligned even if the size is 0? It would be nice to have this stated explicitly in the LangRef. Kind regards, Ralf On 26.03.2018 22:43, Daniel Neilson via llvm-dev wrote: > Hi all, >  A quick note just to let people know that as of

Keno, Hmmm, seems like you are saying “copy-in-copy-out” argument semantics are required by the language, Otherwise you would be using “by-reference" argument semantics, And that CICO is easiest for you to represent with memcpy. Usually there are some very subtle issues with CICO and the memory model, Typically the original object isn’t supposed to be modified until the function

>From copyVector in duplicate.c : void copyVector(SEXP s, SEXP t) { int i, ns, nt; nt = LENGTH(t); ns = LENGTH(s); switch (TYPEOF(s)) { ... case INTSXP: for (i = 0; i < ns; i++) INTEGER(s)[i] = INTEGER(t)[i % nt]; break; ... could that be replaced with : case INTSXP: for (i=0; i<ns/nt; i++) memcpy((char *)DATAPTR(s)+i*nt*sizeof(int),

Hello, It has been a while since my last R Devel build, and now I'm running into an issue I'm not sure how to isolate. After updating to the latest SVN sources, and using: ---<--------------------cut here---------------start------------------->--- tools/rsync-recommended R_PAPERSIZE=letter \ R_BATCHSAVE="--no-save --no-restore" \ R_BROWSER=xdg-open \ LIBnn=lib \

Hello from Bioconductor, I'm developing a package to share R objects across clusters using boost library. The concept is similar to mmap package: https://cran.r-project.org/web/packages/mmap/index.html . However, I have a problem when I was trying to write Dataptr_method for the alternative string. Based on my understanding, the return value of the Dataptr_method function should be a vector

Hi Gabriel, Thanks for your explanation, I totally understand that it is almost impossible to change the data structure of STRSXP. However, what I'm proposing is not about changing the internal representation, but rather about how we design and use the ALTREP API. I might do not state the workarounds clearly as English is not my first language. Please let me explain them again in detail.

Sorry to ask about a bit drifted topic, but will there be an alternative API to DATAPTR? > DATAPTR is not in the API and can't be at least in this form I believe it's vital for ALTREP to return the pointer to the expanded version of a SEXP just like the implementation in base R does [1]. At least, VECSXP has no other measure to expose the pointer if I understand correctly. Best,

On Sat, 8 Jun 2024, Ben Bolker wrote: > The ASAN errors occur *even if the zero-length object is not actually > accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in > base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`, > whereas doing the equivalent in Rcpp will (now) lead to an ASAN error. > > i.e., these are *not*

Experimenting with altrep objects and v3 serialization, I discovered a possible bug. Calling DATAPTR on a compact_intseq object returns a pointer to the expanded integer sequence in memory. If you modify this data, the object values appear to be changed. However, if the compact_intseq object is then serialized (with version=3), only the original integer sequence info is written. For example,

The ASAN errors occur *even if the zero-length object is not actually accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`, whereas doing the equivalent in Rcpp will (now) lead to an ASAN error. i.e., these are *not* previously cryptic out-of-bounds accesses that are now being

Hi all, Consider the following example: define void @fn(i8* %buf) #0 { entry: %arrayidx = getelementptr i8* %buf, i64 18 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %arrayidx, i8* %buf, i64 18, i32 1, i1 false) %arrayidx1 = getelementptr i8* %buf, i64 18 store i8 1, i8* %arrayidx1, align 1 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %buf, i8* %arrayidx, i64 18, i32 1, i1 false)

Hi, I am curious about whether there exist thread-safe functions in `Rinternals.h`. I know that R is single-threaded designed, but for the simple and straightforward functions like `DATAPTR` and `INTEGER_GET_REGION`, are these functions safe to call in a multi-thread environment? Best, Jiefei [[alternative HTML version deleted]]

Hi All, I came across a FileCheck failure I don't understand why. The example code below: void test1() { ... code ... // CHECK-LABEL: @test1 // CHECK: void @llvm.memcpy.p0i8.p0i8.i32 - (1) } void dummy() { // make (1) match ... code ... // CHECK-LABEL: @dummy } void test2() { ... code ... // CHECK-LABEL: @test2 //

The front end I'm building for an existing interpreted language is unfortunately producing output similar to this far too often; define void @foo(i8* nocapture %dest, i8* nocapture %src, i32 %len) nounwind { %1 = tail call noalias i8* @malloc(i32 %len) nounwind tail call void @llvm.memcpy.p0i8.p0i8.i32(i8* %1, i8* %src, i32 %len, i32 1, i1 false) tail call void

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =