<div dir="ltr">Hi Hal,<div><br></div><div>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 <a href="http://llvm.org/bugs/show_bug.cgi?id=20585">http://llvm.org/bugs/show_bug.cgi?id=20585</a>.</div>
<div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-08 12:29 GMT+08:00 Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">----- Original Message -----<br>
> From: "Jiangning Liu" <<a href="mailto:liujiangning1@gmail.com">liujiangning1@gmail.com</a>><br>
> To: <a href="mailto:reviews%2BD4551%2Bpublic%2B38a844dca9087050@reviews.llvm.org">reviews+D4551+public+38a844dca9087050@reviews.llvm.org</a><br>
> Cc: <a href="mailto:gbiv@google.com">gbiv@google.com</a>, <a href="mailto:nlewycky@google.com">nlewycky@google.com</a>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>>, <a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>, "Hal Finkel"<br>

> <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>, "george burgess iv" <<a href="mailto:george.burgess.iv@gmail.com">george.burgess.iv@gmail.com</a>>, <a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>,<br>

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

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

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