[LLVMdev] tbaa differences in llvm 3.0

[Maurice Marks]

Attached is a test case. Using 2.9 opt with -basicaa -tbaa in either order
plus -gvn the code is optimized well, computed values are reused, etc.
because the stores and non aliasing.
Using llvm 3.0 the order of basicaa and tbaa makes a difference: -basicaa
-tbaa optimizes, -tbaa -basicaa doesnt. That's why I tried reversing the
order of calls in the alias analysis pass setup.

On Mon, Jan 30, 2012 at 6:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Fri, 2012-01-27 at 16:46 -0800, Dan Gohman wrote:
> > On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote:
> >
> > > Our application generates IR that is used to generate X86_64 code for
> a Jit. We noticed that code generated with llvm 3.0 is worse in some
> circumstances that it was with 2.9. I traced the differences to alias
> analysis differences. Our IR references data structures that have lots of
> derived pointers and we use extensive tbaa metadata to indicate which
> pointers dont alias. Some of this seemed to be getting ignored in 3.0. I
> found by using opt on our IR that the ordering of the basicaa and tbaa
> optimization passes made all the difference. Code in
> addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From
> Chris' comments in the forum about backward chaining of alais analysis that
> would execute basicaa before tbaa - and that would have the effect of
> basicaa doing the first pass of analysis followed by tbaa, possibly
> overriding the "wont alias" information we provided in the IR.  The
> comments in the code imply that tbaa executes first.
> > >
> > > As an experiment I reversed the order of the passes in
> addInitialAliasAnalysisPasses, rebuilt llvm 3.0 and our application and
> reran our alias  tests. Now we get the same (good) results as llvm 2.9.
> > >
> > > So my question is - which order is correct? I would expect that
> explicit tbaa tags that say that some pointers dont alias should have
> precedence.
> >
> > The intention is for BasicAA to take precedence over TBAA.
> >
> > Whenever BasicAA says MustAlias, it's because the pointers really
> > do alias, even if TBAA would say NoAlias. There's no utility in
> > letting TBAA's NoAlias win in this case, because the code is
> > either intentionally type punning, or it's buggy.
> >
> > There is one special case where BasicAA can't determine the
> > aliasing relationship and still overrides TBAA, which is the case
> > where the two memory locations have the same base address and
> > potentially differing dynamic offsets. Special-casing this is a
> > mild hack used to work around the fact that the TBAA implementation
> > can't easily do the right thing for C code in the real world.
> > Possibly this is causing the loss of precision you're seeing.
>
> Maurice, can you please provide a test case that demonstrates the
> problem that you're seeing?
>
> Dan, where in the code is this done? I see a comment at the end of
> BasicAliasAnalysis::aliasGEP regarding "protecting TBAA in the case of
> dynamic indices into arrays of unions"; are you referring to that?
>
>  -Hal
>
> >
> > Dan
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
>
>


-- 
Not sent from my Blackberry, Raspberry or Gooseberry!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120130/26111bb1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tbaa2.ll
Type: application/octet-stream
Size: 2426 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120130/26111bb1/attachment.obj>