Hi, I'm trying to explore basicaa alias analysis. test.c: int main() { int a; int *p, *q; p = &a; q = p; ... } Commands: clang -emit-llvm -c -g -O0 test.c -o test.bc opt -basicaa -print-must-aliases test.bc However, the result shows that p and q are no alias. Could anyone explain it? Your help is much appreciated! -Haopeng
----- Original Message -----> From: "Haopeng Liu" <hyliuhp at gmail.com> > To: LLVMdev at cs.uiuc.edu > Sent: Thursday, February 19, 2015 6:07:10 PM > Subject: [LLVMdev] basicaa result > > Hi, > > I'm trying to explore basicaa alias analysis. > > test.c: > int main() { > int a; > int *p, *q; > p = &a; > q = p; > ... > } > > Commands: > clang -emit-llvm -c -g -O0 test.c -o test.bc > opt -basicaa -print-must-aliases test.bc > > However, the result shows that p and q are no alias.If you've run only -O0, then you're likely looking at the aliasing of the local stack areas assigned to 'p' and 'q', and they are distinct. -Hal> > Could anyone explain it? Your help is much appreciated! > > -Haopeng > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On 19 February 2015 at 16:07, Haopeng Liu <hyliuhp at gmail.com> wrote:> Hi, > > I'm trying to explore basicaa alias analysis. > > test.c: > int main() { > int a; > int *p, *q; > p = &a; > q = p; > ... > } > > Commands: > clang -emit-llvm -c -g -O0 test.c -o test.bc > opt -basicaa -print-must-aliases test.bc > > However, the result shows that p and q are no alias. > > Could anyone explain it? Your help is much appreciated! >LLVM's alias analysis works on LLVM IR, not on C. The conversion from C to LLVM IR is not as straight-forward as you might at first imagine; for instance, there is no address-of operation in LLVM. Write your examples in LLVM IR, or use clang to produce those examples from C code, but look at the IR it has produced and start thinking about AA results from there. Here's the IR for test.bc: define i32 @main() { entry: %a = alloca i32, align 4 %p = alloca i32*, align 8 %q = alloca i32*, align 8 store i32* %a, i32** %p, align 8 %0 = load i32** %p, align 8 store i32* %0, i32** %q, align 8 ret i32 0 } %p and %q do not alias, they are two separate pointers into the stack. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/d80a6a0e/attachment.html>
It makes sense. Does llvm provide alias analysis on c/c++ which can figure out whether two different pointers in local stack point to same memory? On 2/19/15 8:17 PM, Nick Lewycky wrote:> On 19 February 2015 at 16:07, Haopeng Liu <hyliuhp at gmail.com > <mailto:hyliuhp at gmail.com>> wrote: > > Hi, > > I'm trying to explore basicaa alias analysis. > > test.c: > int main() { > int a; > int *p, *q; > p = &a; > q = p; > ... > } > > Commands: > clang -emit-llvm -c -g -O0 test.c -o test.bc > opt -basicaa -print-must-aliases test.bc > > However, the result shows that p and q are no alias. > > Could anyone explain it? Your help is much appreciated! > > > LLVM's alias analysis works on LLVM IR, not on C. The conversion from > C to LLVM IR is not as straight-forward as you might at first imagine; > for instance, there is no address-of operation in LLVM. Write your > examples in LLVM IR, or use clang to produce those examples from C > code, but look at the IR it has produced and start thinking about AA > results from there. > > Here's the IR for test.bc: > > define i32 @main() { > entry: > %a = alloca i32, align 4 > %p = alloca i32*, align 8 > %q = alloca i32*, align 8 > store i32* %a, i32** %p, align 8 > %0 = load i32** %p, align 8 > store i32* %0, i32** %q, align 8 > ret i32 0 > } > > %p and %q do not alias, they are two separate pointers into the stack. > > Nick-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/51a3a7c9/attachment.html>