search for: memoryus

...or.body: ; preds = %for.body.lr.ph, %for.body ; 3 = MemoryPhi({for.body.lr.ph,liveOnEntry},{for.body,1}) %indvars.iv35 = phi i64 [ 0, %for.body.lr.ph ], [ %indvars.iv.next36, %for.body ] %arrayidx = getelementptr inbounds i32, i32* %b, i64 %indvars.iv35 ; MemoryUse(3) %2 = load i32, i32* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds i32, i32* %c, i64 %indvars.iv35 ; MemoryUse(3) %3 = load i32, i32* %arrayidx2, align 4, !tbaa !2 %add = add nsw i32 %3, %2 %arrayidx4 = getelementptr inbounds i32, i32* %a, i64 %indvars.iv35 *; 1 = Me...

...t; store i8 16, i8* %0 >> br label %4 >> >> ; <label>:3: ; preds = %1 >> br label %4 >> >> ; <label>:4: ; preds = %3, %2 >> ; 3 = MemoryPhi({%3,4},{%2,2}) >> ; MemoryUse(3) >> %5 = load i8, i8* %0 >> ; MemoryUse(1) >> %6 = load i8, i8* %0 >> } >> >> What is the general behavior that I can expect when I insert or remove >> def/use? >> > > So far, it is built to replace all the hoist/sink/removal/etc cases. &...

...tion. Is there a something I can do to prevent this memory leak? Any help would be greatly appreciated. By the way, if you execute the code, please run it in a new R session. # Start of code ================================================================ # Function that returns memory being used MemoryUsed <- function(){ pid <- Sys.getpid() system(paste0("top -n 1 -p ", pid, " -b"), intern = TRUE)[c(7,8)] } # Initial memory (VIRT memory equals about 400,000 bytes on my machine) MemoryUsed() # Create a large list of large data, remove it, and perform garbarge collecti...

...> This is true for def-def relationships, but doesn't;'t matter here. > > So in that sense, from what I understand, it does not actually model the > heap in a fine grained way. > > Any write to any part of the heap will create a new memorydef node. > > Yes, but MemoryUses can reach back past the nearest def, so that doesn't affect uses. The limitation here is deliberately done to keep it only requiring a single phi. All data from building this for years in GCC (which also moved from "precise" to "imprecise" for the same reason) told us th...

...ike to start by trying to show you what is happening when running EarlyCSE with my local changes to use MemorySSA. I've attached a debug log that shows that the value returned by getClobberingMemoryAccess(Inst) after a call to removeMemoryAccess is wrong. The MemorySSA node in question is MemoryUse(7), and the corruption happens after a call to remove MemoryUse(2), at which point its clobber value changes to '1 = MemoryDef(liveOnEntry)'. The interesting thing is that is doesn't seem to be the first call to getClobberingMemoryAccess after the removal that causes the corruptio...

...EarlyCSE with my local changes to use MemorySSA. I've > attached a debug log that shows that the value returned by > getClobberingMemoryAccess(Inst) after a call to > removeMemoryAccess is wrong. The MemorySSA node in > question is MemoryUse(7), and the corruption happens after > a call to remove MemoryUse(2), at which point its clobber > value changes to '1 = MemoryDef(liveOnEntry)'. The > interesting thing is that is doesn't seem to be the first > call to getCl...

...i32*, align 8 %a = alloca i32, align 4 %d = alloca i32, align 4 %c = alloca i32, align 4 %e = alloca i32, align 4 ; 1 = MemoryDef(liveOnEntry) store i32* %b, i32** %b.addr, align 8 ; 2 = MemoryDef(1) store i32 0, i32* %a, align 4 ; 3 = MemoryDef(2) store i32 12, i32* %d, align 4 ; MemoryUse(1) %0 = load i32*, i32** %b.addr, align 8 %tobool = icmp ne i32* %0, null br i1 %tobool, label %if.then, label %if.end if.then: ; preds = %entry ; 4 = MemoryDef(3) store i32 42, i32* %a, align 4 ; 5 = MemoryDef(4) store i32 32, i32* %d, align...

...3 = MemoryPhi +; CHECK-NEXT: %i.0 = phi i32 + %i.0 = phi i32 [ 0, %entry ], [ %i.1, %for.body ] + %cmp = icmp slt i32 %i.0, %N + br i1 %cmp, label %for.body, label %cleanup + +for.body: +; this load doesn't alias either of the stores, so should have a defining access of LiveOnEntry +; CHECK: MemoryUse(liveOnEntry) +; CHECK-NEXT: %loadG1_1 = load + %loadG1_1 = load i16, i16* @G1, align 2 +; CHECK: 1 = MemoryDef(3) +; CHECK-NEXT: store i16 0 + store i16 0, i16* @G2, align 2 + ; ditto for this identical load +; CHECK: MemoryUse(liveOnEntry) +; CHECK-NEXT: %loadG1_2 = load + %loadG1_2 = load i1...

Dear Daniel Berlin, I just tried MemorySSA analysis and get the next IR. However, I feel confused by the result. Specifically, why instruction *%3* relates to a *MemoryDef*. According to my understanding, I think *%3* should be related to a *MemoryUse*, right? ; Function Attrs: uwtable define void @_Z2f1v() #3 personality i32 (...)* @__gxx_personality_v0 { entry: ; 1 = MemoryDef(liveOnEntry) tail call void @checker_thread_begin(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i64 0, i64 0)) ; MemoryUse(1) %0 = load i32, i32* @data1,...

This is definitely a caching bug related to this code: 1038 // Don't try to optimize this phi again if we've already tried to do so. 1039 if (!Q.Visited.insert(PHIPair).second) { 1040 ModifyingAccess = CurrAccess; 1041 break; 1042 } We don't differentiate elsewhere between having stopped at a phi because we were path walking and discovered that path

...:2: ; preds = %1 ; 2 = MemoryDef(4) store i8 16, i8* %0 br label %4 ; <label>:3: ; preds = %1 br label %4 ; <label>:4: ; preds = %3, %2 ; 3 = MemoryPhi({%3,4},{%2,2}) ; MemoryUse(3) %5 = load i8, i8* %0 ; MemoryUse(1) %6 = load i8, i8* %0 } What is the general behavior that I can expect when I insert or remove def/use? Another general question: what is the use of MemorySSAUpdater? When should I use updater and when the MemorySSA API is sufficient? Piotr -------------...

...= alloca i32, align 4 > > %e = alloca i32, align 4 > > ; 1 = MemoryDef(liveOnEntry) > > store i32* %b, i32** %b.addr, align 8 > > ; 2 = MemoryDef(1) > > store i32 0, i32* %a, align 4 > > ; 3 = MemoryDef(2) > > store i32 12, i32* %d, align 4 > > ; MemoryUse(1) > > %0 = load i32*, i32** %b.addr, align 8 > > %tobool = icmp ne i32* %0, null > > br i1 %tobool, label %if.then, label %if.end > > > if.then: ; preds = %entry > > ; 4 = MemoryDef(3) > > store i32 42, i32* %a, a...

...prevent this memory leak? Any help would > be greatly appreciated. By the way, if you execute the code, please run it > in a new R session. > > # Start of code > ================================================================ > > # Function that returns memory being used > MemoryUsed <- function(){ > pid <- Sys.getpid() > system(paste0("top -n 1 -p ", pid, " -b"), intern = TRUE)[c(7,8)] > } > > # Initial memory (VIRT memory equals about 400,000 bytes on my machine) > MemoryUsed() > > # Create a large list of large data, re...

...you what is >> happening when running EarlyCSE with my local changes to use MemorySSA. >> I've attached a debug log that shows that the value returned by >> getClobberingMemoryAccess(Inst) after a call to removeMemoryAccess is >> wrong. The MemorySSA node in question is MemoryUse(7), and the corruption >> happens after a call to remove MemoryUse(2), at which point its clobber >> value changes to '1 = MemoryDef(liveOnEntry)'. The interesting thing is >> that is doesn't seem to be the first call to getClobberingMemoryAccess >> after the r...

On Mon, Apr 27, 2015 at 4:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > You can't win here (believe me, i've tried, and better people than me have > tried, for years :P). > No matter what you do, the partitioning will never be 100% precise. The > only way to solve that in general is to pairwise query over the > partitioning. > > Your basic problem is

Let me try to help. On Thu, Feb 8, 2018 at 12:13 PM, Qiuping Yi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for your explanation. > > Do you mean that LLVM will not maintain the def-use chain for atomic > variables? > It is not a variable at the LLVM level. At the source level, it is a variable. At the LLVM IR level, it is lowered into memory operations. All

...tware info: OS: kUbuntu Feasty Fawn 7.04 (64-bit) Processor: AMD Opteron 64-bit R: version 2.7.0 (64-bit) Cache memory: currently 16 GB (was 2 GB) Outcome of 'limit' command in shell: cputime unlimited, filesize unlimited, datasize unlimited, stacksize 8192 kbytes, coredumpsize 0 kbytes, memoryuse unlimited, vmemoryuse unlimited, descriptors 1024, memorylocked unlimited, maxproc unlimited ----------------------------------- a. We have recently upgraded the cache memory from 2 to 16 GB. However, we have noticed that somehow R still swaps memory when datasets exceeding 2 GB in size are us...

Thanks for your explanation. Do you mean that LLVM will not maintain the def-use chain for atomic variables? So it is impossible to directly catch the fact that the load of x at the statement 'data1 = x; ' dependents on data4 (because of the statement x=data4 )? If I want to get such information, may be the only solution is to traverse all the predecessors of the statement 'data1 =

...mpsize soft = 0,coredumpsize hard = unlimited,openfiles soft = 1024,openfiles hard = 8192,descriptors soft = 1024,descriptors hard = 8192,addressspace soft = unlimited,addressspace hard = unlimited,memorylocked soft = unlimited,memorylocked hard = unlimited,maxproc soft = 16384,maxproc hard = 16384,memoryuse soft = unlimited,memoryuse hard = unlimited null false false false 5 0 /nfs/site/proj/mpgarch/perf/tools/scripts/bin/arch_post.csh /netbatch/ekrimer/task_nhm_296/runs /nfs/site/proj/mpgarch/arch_vpool_1/ekrimer/ambig/results ekrimer 28620 28619 0 Jan28 ? 00:00:00 /bin/csh -f /nfs/site/pr...

...ds around > volatile > ; loads > ; CHECK-LABEL define void @volatile_only > define void @volatile_only(i32* %arg1, i32* %arg2) { > [...] > ; MayAlias > ; CHECK: 2 = MemoryDef(1) > ; CHECK-NEXT: load volatile i32, i32* %arg1 > load volatile i32, i32* %arg1 > ; CHECK: MemoryUse(2) > ; CHECK-NEXT: load i32, i32* %arg2 > load i32, i32* %arg2 > ret void > } > > The testcase: test/Transforms/LICM/volatile-alias.ll checks the > opposite, that we *do* hoist the non-volatile load. This is currently > ensured by the AliasSetTracker. > > > T...