similar to: RFC: Strong GC References in LLVM

Hi Andy, Andrew Trick wrote: > Sanjoy, > > This looks very close to my understanding of the statepoint design trajectory when you first introduced it. It’s great that you followed through and took the time to formalize the IR semantics. It’s been a couple years since I’ve thought about it so I may ask some obtuse questions. > > I think he subject line is wrong though! Did

On Mon, Jul 11, 2016 at 2:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > ping! > > Sanjoy Das wrote: > # Proposed Solution: >> >> We introduce a "new" LLVM type. I will still refer to it as GCREF >> here, but it may actually still be "<ty> addrspace(k)*" where k is >> specially noted in the datalayout. >>

Hi Andy, Andrew Trick wrote: > > I don’t remember why this is important. I often don't know with > InstCombine whether something is needed to expose IR optimization or an > ISEL pattern (which should really be somehow denoted and only run in a > later pass). But for the purposes of this discussion, only the legality (or lack thereof) of the above transform matters, not

Hi Andy, Andrew Trick wrote: >> But for the purposes of this discussion, only the legality (or lack >> thereof) of the above transform matters, not whether it is profitable >> or not. > > Given that you will need to disable the transform for GCRefs, it’s interesting that if it’s only something that needs to run before ISEL then you’re not actually losing any

On Thu, Jul 14, 2016 at 4:48 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi all, > > It looks like the key controversial point is the bit about the extra > control dependence on loads and stores[0]. Generally the consensus is > that (please chime if you think otherwise) it is not reasonable to > make the safety (or semantics) of a load instruction depend

I'm getting this error in my mips16 port. I think that PHI replacement is done in some target independent phase. In the process of debugging this. Maybe to someone else it's obvious how this can happen . tia, Reed *** Bad machine code: MBB exits via unconditional fall-through but its successor differs from its CFG successor! *** - function: main - basic block: BB#0 entry

The following (using if else) did not help. Seemed like joint12 always kicked in. ??? me1<-me0<-NULL. ??? if(joint12){ ????? {me1<-cbind(me1,v1$p12);? me0<-cbind(me0,v0$p12)} ??? } else if(marg1) { ????? {me1<-cbind(me1,v1$p1);?? me0<-cbind(me0,v0$p1)} ??? } else if(marg2) { ????? {me1<-cbind(me1,v1$p2);?? me0<-cbind(me0,v0$p2)} ??? } else if(cond12){ ?????

LLVM Command Line Library I'm proposing a heavy weight command line parsing and generating library for LLVM to replace Clang's parser and provide one for lld and any future tools that may need it. The scope of this library is slightly larger than what Clang has now, but not much. It is centered around the concept of a Tool. A Tool has a set of Options which can be parsed to Arguments or

Can someone help me with the if loop below? In the subroutine, I initialize all of (joint12,marg1,marg2,cond12,cond21) as FALSE, and call with only one of them being TRUE: ,...,joint12=FALSE,marg1=FALSE,marg2=FALSE,cond12=FALSE,cond21=FALSE,,,, joint12 seems to always kick in, even though I call with, e.g., marg1 being TRUE and everything else being FALSE. My attempts with if... else if were

Dear all, When I try to return some vectors from some functions within a function, it indicate an error," Error in rbind(ck1, ck2, ck3) : object 'ck1' not found", in one of the iterations and stop.  Since I am not experienced in programming, can anyone give me a suggestion to inspect this error? The followings are the functions I created : ################### # functions in the

Hi, As a follow up to Patch D23646 <https://reviews.llvm.org/D23646>, I'm trying to figure out if there should be an alignment check and what the correct approach is. Some background: For stores, the pass turns: %i.vec = shuffle <8 x i32> %v0, <8 x i32> %v1, <0, 4, 8, 1, 5, 9, 2, 6, 10, 3, 7, 11> store <12 x i32> %i.vec, <12 x i32>* %ptr

Hi, Your problem is that the function arguments, which are makes as noalias, are not being directly used as the base objects of the array accesses: > %v0.addr = alloca float*, align 8 > %v1.addr = alloca float*, align 8 > %v2.addr = alloca float*, align 8 > %t.addr = alloca float*, align 8 ... > store float* %v0, float** %v0.addr, align 8 > store float* %v1, float** %v1.addr,

Dear R-users I need to calibrate kappa, rho, eta, theta, v0 in the following code, see below. However when I run it, I get: y <- function(kappahat, rhohat, etahat, thetahat, v0hat) {sum(difference(k, t, S0, X, r, implvol, q, kappahat, rhohat, etahat, thetahat, v0hat)^2)} > nlminb(start=list(kappa, rho, eta, theta, v0), objective = y, lower =lb, > upper =ub) Error in dots[[1L]][[1L]] :

Hi, LLVM community: I found basicaa seems not to tell must-not-alias for __restrict__ arguments in c/c++. It only compares two pointers and the underlying objects they point to. I wonder how clang does alias analysis for c/c++ keyword restrict. let assume we compile the following code: $cat myalias.cc float foo(float * __restrict__ v0, float * __restrict__ v1, float * __restrict__ v2, float *

Is something wrong in the initialisation part that we don't see? joint12 <- marg1 <-F marg1 <-T if (joint12) { print ("joint 12") cat (joint12) } if (marg1) { print("marg 1") cat(marg1) } Would probably be my diagnostic approach On Fri, 9 Aug 2024, 04:45 Steven Yen, <styen at ntu.edu.tw> wrote: > Can someone help me with the if loop below?

I"m getting build errors I think from one of your patches O tjoml. You need to have a build area that builds with clang and does warnings as errors to avoid these issues on putback. here is my configure step for example: /home/rkotler/llvm_trunk/configure --enable-werror --prefix=/home/rkotler/ll vm/install CC=/home/rkotler/llvm_3_2/install/bin/clang CXX=/home/rkotler/llvm_3_

On 18/04/16 22:14, Karol Herbst wrote: > we will access the current set cstate at least every second and this safes us saves > some CPU cycles looking them up every second. > > Signed-off-by: Karol Herbst <nouveau at karolherbst.de> > --- > drm/nouveau/include/nvkm/subdev/clk.h | 2 +- > drm/nouveau/nvkm/engine/device/ctrl.c | 5 ++++- >

Hi, I've found a test case where SelectionDAG is doing an undefined behavior optimization, and I need help determining whether or not this is legal. Here is the example IR: define void @test(<4 x i8> addrspace(1)* %out, float %a) { %uint8 = fptoui float %a to i8 %vec = insertelement <4 x i8> <i8 0, i8 0, i8 0, i8 0>, i8 %uint8, i32 0 store <4 x i8> %vec, <4

It is r195843 and fixed in r195905, FYI. 2013/11/29 Reed Kotler <rkotler at mips.com>: > I"m getting build errors I think from one of your patches O tjoml. > > You need to have a build area that builds with clang and does warnings as > errors to avoid these issues on putback. > > here is my configure step for example: > /home/rkotler/llvm_trunk/configure

The patch seems fine but I found it super confusing that sometimes `pstate` is a pointer (for example `clk->pstate`), sometimes it is an int (for example `args->v0.pstate`). On 2017-09-15 — 17:11, Karol Herbst wrote: > We will access the current cstate at least every second and this saves us > some CPU cycles looking them up every second. > > v2: Rewording commit message. >