search for: memorydef

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

...2; 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 i...

...2017 at 1:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Feb 17, 2017 at 1:19 PM, Piotr Padlewski < > piotr.padlewski at gmail.com> wrote: > >> Hi guys, >> a question about updating memory SSA: >> Is it expected that e.g insertion of MemoryDef doesn't change all >> dominated uses? >> > At the moment, it is expected you are essentially just hoisting/sinking > them, not actually changing the aliasing. > The test does not obviously test this constraint, and is pretty contrived. > If you have a use case where we n...

...ttrs: 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 =...

...: > > 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...

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:...

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...

...Use(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 = MemoryDef(3)* store i32 %add, i32* %arrayidx4, align 4, !tbaa !2 %indvars.iv.next36 = add nuw nsw i64 %indvars.iv35, 5 %cmp = icmp slt i64 %indvars.iv.next36, %1 br i1 %cmp, label %for.body, label %for.end for.end: ; preds = %for.body %cmp729 = icmp sgt i3...

...ed as a "new heap state". > 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&quo...

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

I suspect something is pulling the RHS of the memorydef and caching it for calls it should not be used for. In particular, i suspect we are about to discover we can't cache the results from both versions of getClobberingMemoryAccess together, or that the cache is not always getting consistently written. On Mon, May 2, 2016 at 11:16 AM, George Bu...

...reviews.llvm.org at gmail.com> wrote: > > On Sun, Oct 30, 2016 at 6:48 PM, Daniel Berlin <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: >&g...

Hi George, After digging a little deeper, it appears that readonly calls showing up as MemoryDefs is only happening on an EarlyCSE test that is using the new pass manager (test/Transforms/EarlyCSE/basic.ll test5 if you’re curious), so I suspect it is an issue with the new pass manager setup code for either MemorySSA, my changes to EarlyCSE, the test run command line or something else not relat...

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 =

...ySSA's benefits. > Here's a sketch of how I'd think to approach this: > > Visit the MemoryPhi nodes in a loop. Every interesting promotion case > (mod in loop) must be involved in at least one MemoryPhi cycle. > > For each MemoryPhi in the header, create a set of all MemoryDef > instructions involved. (I'm saying this in terms of instructions, but sets > of MemoryLocations should be equivalent.) > > For each instruction in loop, identify it's (optimized) memory def. If > that def is outside loop, and we're looking at a load/store, then we can...

...here is a bug in > making that work :P) > > I suspect the latter, and not the former. > > > On Mon, May 2, 2016 at 11:32 AM, Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>> wrote: > > I suspect something is pulling the RHS of the memorydef and > caching it for calls it should not be used for. > In particular, i suspect we are about to discover we can't cache > the results from both versions of getClobberingMemoryAccess > together, or that the cache is not always getting consistently > written. &...

...additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by MemorySSA which leads to extra walking of MemoryDefs to not regress some EarlyCSE test cases. This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet. George is working on the optimizations, of which this is one. I think this is one of the ones his current patch (under review) addresses....

Hi, Can some one explain the intended behaviour of following loop in void MemorySSAUpdater::insertDef(MemoryDef *MD, bool RenameUses) function. while (!FixupList.empty()) { unsigned StartingPHISize = InsertedPHIs.size(); fixupDefs(FixupList); FixupList.clear(); // Put any new phis on the fixup list, and process them FixupList.append(InsertedPHIs.end() - StartingPHISize, InsertedPHIs.en...

...l b/test/Transforms/Util/MemorySSA/optimize-use.ll index 0ac07b0..45a5097 100644 --- a/test/Transforms/Util/MemorySSA/optimize-use.ll +++ b/test/Transforms/Util/MemorySSA/optimize-use.ll @@ -4,6 +4,7 @@ ; Function Attrs: ssp uwtable define i32 @main() { entry: +; CHECK-LABEL: @main ; CHECK: 1 = MemoryDef(liveOnEntry) ; CHECK-NEXT: %call = call noalias i8* @_Znwm(i64 4) %call = call noalias i8* @_Znwm(i64 4) @@ -35,3 +36,40 @@ entry: } declare noalias i8* @_Znwm(i64) + + at G1 = global i16 zeroinitializer + at G2 = global i16 zeroinitializer + +define void @loop(i32 %N) { +; CHECK-LABEL: @...

...additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by MemorySSA which leads to extra walking of MemoryDefs to not regress some EarlyCSE test cases. This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. I...