[PATCH] LLVM CFL Alias Analysis -- Algorithm

[Jiangning Liu]

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"?

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

http://reviews.llvm.org/D4551