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 AM Alexandros Lamprineas via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi, > > > My understanding is that MemorySSA doesn't know whether memory locations can alias or not. > > > Alexandros > > ________________________________ > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Hayrapetyan, Anahit via llvm-dev <llvm-dev at lists.llvm.org> > Sent: Thursday, August 9, 2018 2:00:14 PM > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] llvm MemorySSA def-use chains > > > 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 > > 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: ; preds = %entry > > ; 4 = MemoryDef(3) > > store i32 42, i32* %a, align 4 > > ; 5 = MemoryDef(4) > > store i32 32, i32* %d, align 4 > > br label %if.end > > > if.end: ; preds = %if.then, %entry > > ; 9 = MemoryPhi({entry,3},{if.then,5}) > > ; MemoryUse(9) > > %1 = load i32, i32* %a, align 4 > > ; 6 = MemoryDef(9) > > store i32 %1, i32* %c, align 4 > > ; MemoryUse(9) > > %2 = load i32, i32* %d, align 4 > > ; 7 = MemoryDef(6) > > store i32 %2, i32* %e, align 4 > > ret void > > } > > > Tracking back def-use chain for `%1 = load i32, i32* %a, align 4` first I get `9 = MemoryPhi({entry,3},{if.then,5})` and then as definitions MemoryDef(2) which corresponds to `store i32 12, i32* %d, align 4` and MemoryDef(4) corresponding to `store i32 32, i32* %d, align 4`. However neither of these stores define `a`, they both define `d`. What I was expecting to get was MemoryDef(3) and MemoryDef(1), which are real definitions for `a`. > > Could you please explain what's the reason MemorySSA gives incorrect definitions, and is there any way to get the correct ones. > > > Thanks. > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hayrapetyan, Anahit via llvm-dev
2018-Aug-11 11:09 UTC
[llvm-dev] llvm MemorySSA def-use chains
Hi Sebastian, Thanks for the answer. I've tried to run memoryssa piping it with alias analysis, as you've suggested, however the output is still the same. As a def for use of a I'm still getting a def of d. ________________________________ From: Sebastian Pop <sebpop.llvm at gmail.com> Sent: Friday, August 10, 2018 10:58 PM To: Alexandros.Lamprineas at arm.com Cc: Hayrapetyan, Anahit; LLVM Dev Subject: Re: [llvm-dev] llvm MemorySSA def-use chains 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 AM Alexandros Lamprineas via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi, > > > My understanding is that MemorySSA doesn't know whether memory locations can alias or not. > > > Alexandros > > ________________________________ > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Hayrapetyan, Anahit via llvm-dev <llvm-dev at lists.llvm.org> > Sent: Thursday, August 9, 2018 2:00:14 PM > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] llvm MemorySSA def-use chains > > > 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 > > 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: ; preds = %entry > > ; 4 = MemoryDef(3) > > store i32 42, i32* %a, align 4 > > ; 5 = MemoryDef(4) > > store i32 32, i32* %d, align 4 > > br label %if.end > > > if.end: ; preds = %if.then, %entry > > ; 9 = MemoryPhi({entry,3},{if.then,5}) > > ; MemoryUse(9) > > %1 = load i32, i32* %a, align 4 > > ; 6 = MemoryDef(9) > > store i32 %1, i32* %c, align 4 > > ; MemoryUse(9) > > %2 = load i32, i32* %d, align 4 > > ; 7 = MemoryDef(6) > > store i32 %2, i32* %e, align 4 > > ret void > > } > > > Tracking back def-use chain for `%1 = load i32, i32* %a, align 4` first I get `9 = MemoryPhi({entry,3},{if.then,5})` and then as definitions MemoryDef(2) which corresponds to `store i32 12, i32* %d, align 4` and MemoryDef(4) corresponding to `store i32 32, i32* %d, align 4`. However neither of these stores define `a`, they both define `d`. What I was expecting to get was MemoryDef(3) and MemoryDef(1), which are real definitions for `a`. > > Could you please explain what's the reason MemorySSA gives incorrect definitions, and is there any way to get the correct ones. > > > Thanks. > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180811/cb2f3122/attachment.html>
You can see that there's a chain between def-def as well - meaning that the later def updates the former def. Hence the result is not incorrect, it is just inaccurate. For brevity of memory ssa, LLVM (as well as GCC) is maintaining at most 1 'latest' def per block. (https://llvm.org/docs/MemorySSA.html#precision , keyword 'partition' means something similar to the number of latest def) You can test GCC with -fno-tree-vectorize -fdump-tree-all-vops as well. In your example, 3 is the latest def of block entry, and 5 is the latest def of block if.then. Having more than one latest def can increase number of MemoryPhis. Verbose ssa generation is bad for for compilation time & memory footprint. Best Regards, Juneyoung Lee On Sat, Aug 11, 2018 at 8:09 PM, Hayrapetyan, Anahit via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > Hi Sebastian, > > Thanks for the answer. I've tried to run memoryssa piping it with alias > analysis, as you've suggested, however the output is still the same. As a > def for use of *a *I'm still getting a def of *d.* > > ------------------------------ > *From:* Sebastian Pop <sebpop.llvm at gmail.com> > *Sent:* Friday, August 10, 2018 10:58 PM > *To:* Alexandros.Lamprineas at arm.com > *Cc:* Hayrapetyan, Anahit; LLVM Dev > *Subject:* Re: [llvm-dev] llvm MemorySSA def-use chains > > 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 AM Alexandros Lamprineas via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > > > My understanding is that MemorySSA doesn't know whether memory locations > can alias or not. > > > > > > Alexandros > > > > ________________________________ > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of > Hayrapetyan, Anahit via llvm-dev <llvm-dev at lists.llvm.org> > > Sent: Thursday, August 9, 2018 2:00:14 PM > > To: llvm-dev at lists.llvm.org > > Subject: [llvm-dev] llvm MemorySSA def-use chains > > > > > > 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 > > > > 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: ; preds = %entry > > > > ; 4 = MemoryDef(3) > > > > store i32 42, i32* %a, align 4 > > > > ; 5 = MemoryDef(4) > > > > store i32 32, i32* %d, align 4 > > > > br label %if.end > > > > > > if.end: ; preds = %if.then, > %entry > > > > ; 9 = MemoryPhi({entry,3},{if.then,5}) > > > > ; MemoryUse(9) > > > > %1 = load i32, i32* %a, align 4 > > > > ; 6 = MemoryDef(9) > > > > store i32 %1, i32* %c, align 4 > > > > ; MemoryUse(9) > > > > %2 = load i32, i32* %d, align 4 > > > > ; 7 = MemoryDef(6) > > > > store i32 %2, i32* %e, align 4 > > > > ret void > > > > } > > > > > > Tracking back def-use chain for `%1 = load i32, i32* %a, align 4` first > I get `9 = MemoryPhi({entry,3},{if.then,5})` and then as definitions > MemoryDef(2) which corresponds to `store i32 12, i32* %d, align 4` and > MemoryDef(4) corresponding to `store i32 32, i32* %d, align 4`. However > neither of these stores define `a`, they both define `d`. What I was > expecting to get was MemoryDef(3) and MemoryDef(1), which are real > definitions for `a`. > > > > Could you please explain what's the reason MemorySSA gives incorrect > definitions, and is there any way to get the correct ones. > > > > > > Thanks. > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- Juneyoung Lee Software Foundation Lab, Seoul National University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180812/52d123ce/attachment.html>