[PATCH] LLVM CFL Alias Analysis -- Algorithm

[Hal Finkel]

----- Original Message -----
> From: "Jiangning Liu" <liujiangning1 at gmail.com>
> To: reviews+D4551+public+38a844dca9087050 at reviews.llvm.org
> Cc: gbiv at google.com, nlewycky at google.com, "Chandler Carruth" <chandlerc at gmail.com>, dberlin at dberlin.org, "Hal Finkel"
> <hfinkel at anl.gov>, "george burgess iv" <george.burgess.iv at gmail.com>, sanjoy at playingwithpointers.com,
> "llvm-commits at cs.uiuc.edu for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Thursday, August 7, 2014 10:38:17 PM
> Subject: Re: [PATCH] LLVM CFL Alias Analysis -- Algorithm
> 
> 
> Hi George,
> 
> 
> Thanks for your answer!
> 
> 
> I'm asking this question, because the feature -strict-aliasing can
> improve benchmark performance a lot. And even one of spec2000
> benchmarks, I can see ~6% performance improvement.
> 
> 
> I simplified one of the cases as below,
> 
> 
> {code}
> 
> $ cat alias.c
> typedef struct {int x; int y;} S;
> S **ps;
> int i;
> main()
> {
> do {
> ps[i]->x = i;
> i++;
> } while (i);
> }
> $ ~/llvm/build/bin/clang --target=aarch64-linux-gnuabi alias.c -S -O2
> alias.c:4:1: warning: type specifier missing, defaults to 'int'
> [-Wimplicit-int]
> main()
> ^
> 1 warning generated.
> $ cat alias.s
> .text
> .file "alias.c"
> .globl main
> .align 2
> .type main, at function
> main: // @main
> // BB#0: // %entry
> adrp x9, ps
> adrp x8, i
> ldr x9, [x9, :lo12:ps]
> ldr w10, [x8, :lo12:i]
> .LBB0_1: // %do.body
> // =>This Inner Loop Header: Depth=1
> ldr x11, [x9, w10, sxtw #3]
> str w10, [x11]
> ldr w10, [x8, :lo12:i] // inside the loop
> add w10, w10, #1 // =1
> str w10, [x8, :lo12:i] // inside the loop
> cbnz w10, .LBB0_1
> // BB#2: // %do.end
> mov w0, wzr
> ret
> .Ltmp1:
> .size main, .Ltmp1-main
> 
> 
> .type i, at object // @i
> .comm i,4,4
> .type ps, at object // @ps
> .comm ps,8,8
> 
> 
> .ident "clang version 3.6.0 "
> $ aarch64-linux-gnu-gcc alias.c -S -O2
> $ cat alias.s
> .cpu generic
> .file "alias.c"
> .section .text.startup,"ax",%progbits
> .align 2
> .global main
> .type main, %function
> main:
> adrp x4, i
> adrp x1, ps
> ldr w0, [x4,#:lo12:i] // hoisted out loop
> ldr x1, [x1,#:lo12:ps]
> add x1, x1, x0, sxtw 3
> b .L3
> .L5:
> mov w0, w2
> .L3:
> ldr x3, [x1],8
> adds w2, w0, 1
> str w0, [x3]
> bne .L5
> str w2, [x4,#:lo12:i] // sink out of loop
> ret
> .size main, .-main
> .comm i,4,4
> .comm ps,8,8
> .ident "GCC: (Ubuntu/Linaro 4.8.1-10ubuntu7) 4.8.1"
> {code}
> 
> 
> So for this case, gcc can hoist/sink load/store out of loop, but llvm
> can't.
> 
> 
> Is the goal of your new design to replace the current "BasicAA+TBAA"?
> 

George's current work plugs into our current AA infrastructure, and supplements BasicAA (and will perhaps be able to replace BasicAA for some classes of queries). TBAA is a separate analysis, and nothing George has done makes it any better or worse.

Regarding TBAA, I recommend that we move that discussion to a different thread. The issue you highlight, for example, is certainly something we should fix, and I don't see any reason why our current TBAA infrastructure could not cope with it. Please file a bug report.

Thanks again,
Hal

> 
> 
> Sorry for my off topic discussion, but I want to understand what is
> going to happen around this. Our stakeholders really want
> performance improvement.
> 
> 
> Based on your last reply, my understanding is we should improve TBAA,
> but will it still work together with your new design? Should we pay
> effort on current TBAA pass to solve the problem?
> 
> 
> Thanks,
> -Jiangning
> 
> 
> 
> 
> 
> 2014-08-08 2:40 GMT+08:00 George Burgess IV < gbiv at google.com > :
> 
> 
> Hi! Thanks for your comments :)
> 
> 
> > Kevin posted this
> > http://comments.gmane.org/gmane.comp.compilers.llvm.devel/75298 .
> AFAICT, that's not a valid C program. The C89 standard section
> 3.1.2.6 says "All declarations that refer to the same object or
> function shall have compatible type; otherwise the behavior is
> undefined." In this case, the types int and `struct heap` are not
> compatible. So, undefined behavior results. For more on type
> compatibility in C89, see section 3.1.2.6 of the standard. Compiling
> the executable with `-fno-strict-aliasing -O2` on gcc 4.8.2 & clang
> 3.4.1, it seems that they both produce *very* similar assembly. In
> terms of pure instruction count, clang actually "wins" by a single
> instruction.
> 
> 
> > Will this new design supporting "strict aliasing" finally?
> This AA algorithm entirely ignores types at the moment. That being
> said, if we have an API that allows us to extract C/C++ types from
> LLVM IR, I don't see adding type sensitivity being a necessarily
> difficult task. (If you're only looking for a pass that deals with
> types, then you may find that the TypeBasedAliasAnalysis pass
> interesting.)
> 
> Thanks again,
> George
> 
> http://reviews.llvm.org/D4551
> 
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory