search for: liveonentry

...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 corruption, but rather the second. You'll notice that I added calls to getClobberingMemoryAccess when doing MSSA.dump(), which is what I'm usin...

...n't sure if this was a known issue that you'll be addressing in your upcoming walker caching changes or not, so I haven't investigated it very much. The test case is attached. The bug is that the defining access for the second load is set to the loop MemoryPhi node instead of being liveOnEntry as it should be as I understand things. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- diff --git a/test/Transforms/Util/MemorySSA/op...

...traint, and is pretty contrived. > If you have a use case where we need to rename affected uses, i'm happy to > make it do that, it's trivial. > > >> For example test case CreateLoadsAndStoreUpdater produces: >> >> define void @F(i8*) { >> ; 1 = MemoryDef(liveOnEntry) >> store i8 16, i8* %0 >> ; 4 = MemoryDef(1) >> store i8 16, i8* %0 >> br i1 true, label %2, label %3 >> >> ; <label>:2: ; preds = %1 >> ; 2 = MemoryDef(4) >> store i8 16, i8* %0 >> br label...

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

...gt;&1 The relevant parts of the file "out" are shown below: . . . for.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....

...; define void @foo(i64* nocapture %P, i64* %Q) { > entry: > %0 = bitcast i64* %P to i16* > %arrayidx = getelementptr inbounds i16, i16* %0, i64 1 > %1 = bitcast i16* %arrayidx to i32* > %arrayidx1 = getelementptr inbounds i16, i16* %0, i64 3 > ; 1 = MemoryDef(liveOnEntry) > store i16 0, i16* %0, align 2 > ; 2 = MemoryDef(1) > store i32 0, i32* %1, align 4 > ; 3 = MemoryDef(2) > store i16 0, i16* %arrayidx1, align 2 > ; 4 = MemoryDef(3) > store i64 0, i64* %Q > ret void > } > > Specifically, a memset is fi...

...e if this was a known issue that you'll be addressing in your upcoming > walker caching changes or not, so I haven't investigated it very much. The > test case is attached. The bug is that the defining access for the second > load is set to the loop MemoryPhi node instead of being liveOnEntry as it > should be as I understand things. > > -- > Geoff Berry > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > -------------- next part -------------- An HT...

Hi guys, a question about updating memory SSA: Is it expected that e.g insertion of MemoryDef doesn't change all dominated uses? For example test case CreateLoadsAndStoreUpdater produces: define void @F(i8*) { ; 1 = MemoryDef(liveOnEntry) store i8 16, i8* %0 ; 4 = MemoryDef(1) store i8 16, i8* %0 br i1 true, label %2, label %3 ; <label>:2: ; preds = %1 ; 2 = MemoryDef(4) store i8 16, i8* %0 br label %4 ; <label>:3: ; preds = %1 br la...

...eturned 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 corruption, but rather the second. >> You'll notice that I added calls to getClobberingMemoryAccess when doing >> MSSA.dump...

...d = 32; } int c = a; int e = d; } ; Function Attrs: noinline nounwind optnone uwtable define void @foo(i32* %b) #0 { entry: %b.addr = alloca 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:...

...r > will naturally lead to different outcomes. > So, how can I make progress here? > > > I think it's reasonable in D40375 <https://reviews.llvm.org/D40375> to > have pointerInvalidatedByLoopWithMSSA only check if the defining > access is within the current loop or liveOnEntry, and rely on > MemorySSA to either consider a volatile load a clobbering access or > not. So, right now the LICM/volatile-alias.ll testcase will behave > differently with MemorySSA enabled. > > A separate decision, is whether to update getLoadReorderability in > MemorySSA to r...

...line nounwind optnone uwtable > > define void @foo(i32* %b) #0 { > > entry: > > %b.addr = alloca 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*...

...cess(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 corruption, but rather the second. You'll > notice that I added calls to getClobbering...

...hown below: >> . >> . >> . >> >> for.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 >> %arrayidx...

...eel 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, align 4, !tbaa !1 %cmp = icmp sgt i32 %0, 0 br i1 %cmp, label %if.then, label %entry.if.end_crit_edge entry.if.end_crit_edge:...

...rlin <dberlin at dberlin.org> > wrote: > >> In particular: >> " >> I'm not so sure that it's sufficient. Suppose, for instance, that I >> wanted to insert a MemoryDef between 1 and 2 in the below AccessList: >> >> >> 0 = MemoryDef(liveOnEntry) >> 1 = MemoryDef(0) >> 2 = MemoryDef(1) >> 3 = MemoryUse(1) >> >> Invoking createMemoryAccess followed by RAUW of 1's uses with 4 would >> result in: >> .... >> " >> >> Which is why this is not the way one does this, anywhe...

On 12/20/2017 1:37 PM, Sanjoy Das wrote:> > Fwiw, I was under the impression that regular loads could *not* be > reordered with volatile loads since we could have e.g.: > > int *normal = &global_variable; > volatile int* ptr = 0; > int k = *ptr; // segfaults, and the signal handler writes to *normal > int value = *normal; > > and that we'd have

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

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 =