[LLVMdev] Question about Alias Analysis

Ben Chambers bjchambers at gmail.com
Mon Jun 25 13:29:29 PDT 2007


Hi!  I'm currently working on developing a new technique for alias
analysis and wish to know how to compare it's results to the results
that LLVM gets.  The algorithm I have operates on LLVM assembly (I
wrote the analysis in Haskell, so unfortunately I can't embed it into
LLVM  very easily).  I tried using the option to print alias sets, but
I'm not quite sure how to interpret the results (or even if this is an
accurate measure of the alias information provided by LLVM.  I took a
simple program (shown below) and compiled it with llvm-gcc -O0 (I
didn't want it to optimize away the code).  The output I got (using
-basicaa -anders-aa -show-alias-sets) is also shown below.

I guess what confuses me is that it doesn't seem like it was able to
figure out that *b = a.  Am I looking at this wrong?  Is there a more
accurate way of getting the alias information out of the pass?

Thanks,
Ben Chambers

Output:
 AliasSet[0x601e70,2] may  alias, Mod/Ref   Pointers: (i32* %a, 4),
(i32* %tmp1, 4)
 AliasSet[0x601ea0,1] must alias, Mod/Ref   Pointers: (i32** %b, 4)
 AliasSet[0x601f10,1] must alias, Mod/Ref   Pointers: (i32* %tmp, 4)
 AliasSet[0x601f60,1] must alias, Mod/Ref   Pointers: (i32* %retval, 4)

Input:

int main() {
 int a = 5;
 int* b = &a;
 return *b;
}

Assembly:

define i32 @main() {
entry:
 %retval = alloca i32, align 4   ; <i32*> [#uses=2]
 %tmp = alloca i32, align 4    ; <i32*> [#uses=2]
 %a = alloca i32, align 4    ; <i32*> [#uses=2]
 %b = alloca i32*, align 4   ; <i32**> [#uses=2]
 "alloca point" = bitcast i32 0 to i32   ; <i32> [#uses=0]
 store i32 5, i32* %a
 store i32* %a, i32** %b
 %tmp1 = load i32** %b   ; <i32*> [#uses=1]
 %tmp2 = load i32* %tmp1   ; <i32> [#uses=1]
 store i32 %tmp2, i32* %tmp
 %tmp3 = load i32* %tmp    ; <i32> [#uses=1]
 store i32 %tmp3, i32* %retval
 br label %return

return:   ; preds = %entry
 %retval4 = load i32* %retval    ; <i32> [#uses=1]
 ret i32 %retval4
}



More information about the llvm-dev mailing list