search for: ptr0

...+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c @@ -137,15 +137,29 @@ gk104_ectx_bind(struct nvkm_engn *engn, struct nvkm_cctx *cctx, struct nvkm_chan u64 addr = 0ULL; switch (engn->engine->subdev.type) { - case NVKM_ENGINE_SW : return; - case NVKM_ENGINE_GR : ptr0 = 0x0210; break; - case NVKM_ENGINE_SEC : ptr0 = 0x0220; break; - case NVKM_ENGINE_MSPDEC: ptr0 = 0x0250; break; - case NVKM_ENGINE_MSPPP : ptr0 = 0x0260; break; - case NVKM_ENGINE_MSVLD : ptr0 = 0x0270; break; - case NVKM_ENGINE_VIC : ptr0 = 0x0280; break; - case NVKM_ENGINE_...

...+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c @@ -137,15 +137,29 @@ gk104_ectx_bind(struct nvkm_engn *engn, struct nvkm_cctx *cctx, struct nvkm_chan u64 addr = 0ULL; switch (engn->engine->subdev.type) { - case NVKM_ENGINE_SW : return; - case NVKM_ENGINE_GR : ptr0 = 0x0210; break; - case NVKM_ENGINE_SEC : ptr0 = 0x0220; break; - case NVKM_ENGINE_MSPDEC: ptr0 = 0x0250; break; - case NVKM_ENGINE_MSPPP : ptr0 = 0x0260; break; - case NVKM_ENGINE_MSVLD : ptr0 = 0x0270; break; - case NVKM_ENGINE_VIC : ptr0 = 0x0280; break; - case NVKM_ENGINE_...

...engine/fifo/gk104.c > @@ -137,15 +137,29 @@ gk104_ectx_bind(struct nvkm_engn *engn, struct > nvkm_cctx *cctx, struct nvkm_chan > u64 addr = 0ULL; > > switch (engn->engine->subdev.type) { > - case NVKM_ENGINE_SW : return; > - case NVKM_ENGINE_GR : ptr0 = 0x0210; break; > - case NVKM_ENGINE_SEC : ptr0 = 0x0220; break; > - case NVKM_ENGINE_MSPDEC: ptr0 = 0x0250; break; > - case NVKM_ENGINE_MSPPP : ptr0 = 0x0260; break; > - case NVKM_ENGINE_MSVLD : ptr0 = 0x0270; break; > - case NVKM_ENGINE_VIC : ptr0 = 0x0280; brea...

...engine/fifo/gk104.c > @@ -137,15 +137,29 @@ gk104_ectx_bind(struct nvkm_engn *engn, struct > nvkm_cctx *cctx, struct nvkm_chan > u64 addr = 0ULL; > > switch (engn->engine->subdev.type) { > - case NVKM_ENGINE_SW : return; > - case NVKM_ENGINE_GR : ptr0 = 0x0210; break; > - case NVKM_ENGINE_SEC : ptr0 = 0x0220; break; > - case NVKM_ENGINE_MSPDEC: ptr0 = 0x0250; break; > - case NVKM_ENGINE_MSPPP : ptr0 = 0x0260; break; > - case NVKM_ENGINE_MSVLD : ptr0 = 0x0270; break; > - case NVKM_ENGINE_VIC : ptr0 = 0x0280; brea...

On Tue, Apr 11, 2017 at 3:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Kostya, > > On April 11, 2017 at 2:39:44 PM, Kostya Serebryany (kcc at google.com) wrote: > > > ptr0 = malloc(); > > > free(ptr0); > > > ptr1 = malloc(); > > > > > > ptr0 and ptr1 will be NoAlias despite overlapping (there is actually a > > > real soundness issue here in LLVM's semantics, but I don't want to > > > digress). You can also...

...there should (??) be a point in the IR where both P1 and P2 exist > together > > > and can be compared. > > > > That may not be possible (though I'm second guessing what exactly you > have in mind so maybe > > I'm missing something here): > > > > ptr0 = malloc(); > > *(int*)ptr0 = 20; // access0 > > free(ptr0); > > ptr1 = calloc(); // bitwise equal to ptr0 by chance > > float f = *(float *)ptr1; // access1 > > > > The program above is fine (no TBAA violations), but at location access1 > ptr1 and ptr0 > &...

...s, and if TBAA queries > MayAlias(AccessViaP1, AccessViaP2) > there should (??) be a point in the IR where both P1 and P2 exist together > and can be compared. That may not be possible (though I'm second guessing what exactly you have in mind so maybe I'm missing something here): ptr0 = malloc(); *(int*)ptr0 = 20;  // access0 free(ptr0); ptr1 = calloc();   // bitwise equal to ptr0 by chance float f = *(float *)ptr1;  // access1 The program above is fine (no TBAA violations), but at location access1 ptr1 and ptr0 overlap despite being NoAlias. -- Sanjoy > > > > &gt...

...e mangling used for llvm-ir functions (See [0, 3]). The problem is the following: Given: %0 = type { i32 } %1 = type { i32 } Creating an intrinsic @llvm.FOO that accepts 'a pointer to %0' cannot be distinguished from the intrinsic accepting 'a pointer to %1': ;For a %0* ptr0, %1* ptr1 call @llvm.FOO.p0s_s %0* %ptr0 call @llvm.FOO.p0s_s %1* %ptr1 ; assertion failure: same name produced, but %ptr1 is not compatible with '%0*' It seems that the name mangling is not coping well with anonymous structs ? See: [1,2]: All anonymous structs get a 's_s...

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I’m not sure how transforming GEP offset to i8 type will help alias >> analysis & SROA for the mentioned test case. > > It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent. > Since memory isn't

.../* how big? */ - c->nearest_tree=a=_ogg_calloc(1,sizeof(encode_aux_nearestmatch)); + c->nearest_tree=a=(encode_aux_nearestmatch*)_ogg_calloc(1,sizeof(encode_aux_nearestmatch)); line=get_line(in); line=get_line(in); @@ -230,5 +231,5 @@ find_seek_to(in,"static long _vq_ptr0"); reset_next_value(); - a->ptr0=_ogg_malloc(sizeof(long)*a->aux); + a->ptr0=(long*)_ogg_malloc(sizeof(long)*a->aux); for(i=0;i<a->aux;i++) if(get_next_ivalue(in,a->ptr0+i)){ @@ -240,5 +241,5 @@ find_seek_to(in,"static long _vq_ptr1");...

On 2008-07-07, at 05:40, Benedict Gaster wrote: > %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* > %ptr0, i32 4) > %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* > %ptr11, i32 4) > call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, > i32 11, i1 false) ; force read-modify-write %ptr11 to complete > > A problem with this approach is that developing...

...: declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i32 addrspace, i1 <device> ) and we can now write the code: @llvm.atomic.load.add.p0i32 @llvm.atomic.load.add.p11i32 %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* %ptr0, i32 4) %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* %ptr11, i32 4) call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, i32 11, i1 false) ; force read-modify-write %ptr11 to complete A problem with this approach is that developing a new pass over the IL...

...as part of the type as will be the case with the other atomic operations. What do you think? Ben On 7 Jul 2008, at 13:43, Gordon Henriksen wrote: > On 2008-07-07, at 05:40, Benedict Gaster wrote: > >> %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* >> %ptr0, i32 4) >> %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* >> %ptr11, i32 4) >> call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, >> i32 11, i1 false) ; force read-modify-write %ptr11 to complete >> >> A problem with this appr...

Hi, I got pulled off doing other things last week but I plan to get the support for address spaces to the intrinsics this week. As Benedict noted, the problem is that we don't carry the address space information with the intrinsics. Today, we will do an implicit cast to the default address space. My change will prevent that from happening by allowing the intrinsic to have a

> > >> Sanjoy’s argument is faulty, if it were true we would also find our >> handling of “assert” to be unacceptable >> >> but this is not the case, no one is arguing that we need to re-design >> “assert” >> > Sure, but no one should make this argument anyway: assert is not for > optimization. In fact, we don't really want it to be used for

...ill a single two byte store). So is it (always) correct to interpret the list of MachineMemOperands as the instruction will store to one of the locations? Is perhaps allowed for a backend to have a store instruction that that actually stores to multiple locations at once, such as: MultiStoreInstr $ptr0, 1, $ptr1, 2, $ptr2, 18 :: (store 2 intro %my.ptr0.var), (store 2 intro %my.ptr1.var), (store 2 intro %my.ptr2.var) (maybe that is impossible for other reasons). Background to my questions: The problem with the rewrite done by BranchFolder is that it sometimes mess up alias analysis. In fact, Mac...

Hi, On April 11, 2017 at 11:55:12 AM, Kostya Serebryany via llvm-dev (llvm-dev at lists.llvm.org) wrote: > Evgeniy and I recently discussed something similar for detecting bad casts > (code named: TypeSanitizer). > The approach with the shadow memory looked attractive at the first glance, > but then we've drowned in details. > > Specifically for TBAA, I had another idea, not

...se with the other atomic operations. What do > you think? > > Ben > > On 7 Jul 2008, at 13:43, Gordon Henriksen wrote: > >> On 2008-07-07, at 05:40, Benedict Gaster wrote: >> >>> %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* >>> %ptr0, i32 4) >>> %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* >>> %ptr11, i32 4) >>> call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 >>> false, >>> i32 11, i1 false) ; force read-modify-write %ptr11 to complete >>&gt...

...t. Are there specific passes in-tree that you’ve seen do this? Are they just passing values through alloca? We shouldn’t need to worry about general heap access doing this. Is there any other reason a pass would load an address as i64? InstCombine today will transform %v = load i32*, i32** %ptr0 store i32* %v, i32** %ptr1 into %1 = bitcast i32** %ptr0 to i64* %v1 = load i64, i64* %1, align 8 %2 = bitcast i32** %ptr1 to i64* store i64 %v1, i64* %2, align 8 > >> ## GCREF -> Integer conversion >> >> Converting a GCREF to an integer is fine if the...

Hi Danny, Thanks for that :) However I've just updated the prototype patch to NewGVN and it didn't need any API changes - all I rely on is GVNExpression. Hongbin, I wanted to explain a little about what GVNSink can currently do, what it was designed for and hopefully how to make it handle your testcase. *Background* Common code sinking is more difficult to efficently do than one might