[PATCH] LLVM CFL Alias Analysis -- Algorithm

[Jiangning Liu]

Hi Hal,

Thanks a lot for your explanation, and now the picture of LLVM AA is a
little bit clear to me. I filed a bug at
http://llvm.org/bugs/show_bug.cgi?id=20585.

Thanks,
-Jiangning



2014-08-08 12:29 GMT+08:00 Hal Finkel <hfinkel at anl.gov>:

> ----- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140808/dfa35775/attachment.html>