search for: memorydefs

Hi guys, I think I have run into another CachingMemorySSAWalker cache bug. It's a bit tricky to reproduce, so I'd like 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

Hi, I have a question about how llvm MemorySSA works, as seems I misunderstand something. Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa) void foo(int* b) { int a = 0; int d = 12; if (b) { a = 42; d = 32; } int c = a; int e = d; } ; Function Attrs: noinline nounwind optnone uwtable

In particular, if you want to add support, the right way to know what to rename is (off the top of my head) add a flag or something to have renamepass reset all uses it sees (you only have to change the uses, defs are all linked together and thus already fixed by the updater). Right now it only does that if they have no defining access. Make it skip blocks already in the visited set (the

Hi, try adding some alias analysis to the pipeline: see examples in llvm/test/Analysis/MemorySSA/*.ll for example assume.ll has ; RUN: opt -aa-pipeline=basic-aa -passes='print<memoryssa>,verify<memoryssa>' without basic-aa the memory ssa will safely assume that the stores to %a and %d alias which may be proven disjoint by one of the alias analyses. On Thu, Aug 9, 2018 at 8:37

...MemoryDef(3) > call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 8, i32 2, i1 false) > ; new > > ; 4 = MemoryDef(3) > store i64 0, i64* %Q > ret void > } > > This is already problematic because there's no way to selectively update > the > post-5 MemoryDefs that point to 5 instead of 3. Calling RAUW -- > specifically, > replacing all uses of 3 with 5 -- would result in this: > I'm aware the existing APIs will not do what you want, because, as i said, they are specifically and documented to only be meant for replacement. When i origina...

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)

Hi, I am new to MemorySSA and wanted to understand its capabilities. Hence I wrote the following program (test.c): int N; void test(int *restrict a, int *restrict b, int *restrict c, int *restrict d, int *restrict e) { int i; for (i = 0; i < N; i = i + 5) { a[i] = b[i] + c[i]; } for (i = 0; i < N - 5; i = i + 5) { e[i] = a[i] * d[i]; } } I compiled this program using

On Tue, Dec 19, 2017 at 9:10 AM, Siddharth Bhat via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I could be entirely wrong, but from my understanding of memorySSA, each > def defines an "abstract heap state" which has the coarsest possible > definition - any write will be modelled as a "new heap state". > This is true for def-def relationships, but

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 Burgess IV < george.burgess.iv at

On Sun, Oct 30, 2016 at 4:08 PM, Bryant Wong < 3.14472+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

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

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 =

...ly see > the problem there. Even then, constructing an AST for only the > instructions involved in a loop MemoryPhi cycle should be pretty cheap. > AFAIK there is no notion of MemoryPhis being optimized. Each block has a *single* MemoryPhi, which has the last Def from each incoming block. MemoryDefs and MemoryUses can be optimized through Phis. MemoryDefs are also not optimized from the start, only MemoryUses are. All MemoryDefs build a single def chain, regardless of whether they alias or not. Doing alias sets means checking alias() at least for all pairs of Defs, since alias relation is not...

I've put my changes to EarlyCSE that trigger this case up on phab here: http://reviews.llvm.org/D19821. These changes depend on http://reviews.llvm.org/D19664 so that will need to be applied first. With these changes applied, the original attached .ll file should trigger this bug when compiled with opt -early-cse -early-cse-use-memoryssa On 5/2/2016 2:34 PM, Daniel Berlin wrote: >

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

Hey All, I've come across what I believe to be a bug in MemorySSA. George, I wasn'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

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