<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 1:50 AM, Ivan A. Kosarev via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I'm trying to get the whole picture of what we are doing in terms<br>
of alias analysis in LLVM. Being new to this I may be missing<br>
some well known things so my apologies if I seem to ask obvious<br>
things.<br>
<br>
There are lots of questions arise in my head as I read related<br>
bug reports, sources and documentation, of which looks to be the<br>
most simple is,<br>
<br>
Why the current TBAA implementation returns NoAlias for pairs of<br>
accesses for which it has no idea if they really alias?<br></blockquote><div><br></div><div>TBAA is broken in various ways, but in general, it is because it knows they can't legally do so.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Let me elaborate on this. My understanding of what the TBAA<br>
implementation is supposed to respond is whether a given pair of<br>
accesses is allowed to alias by the rules of the input language.<br></blockquote><div>No.</div><div>TBAA is a bad name for what LLVM is doing, because it's not really TBAA at that point.  I've objected to the name before as it confuses people.</div><div>It's really anti-alias sets/subsets structured as a tree.  Loads/stores are tagged with which set they belong to.</div><div><br></div><div>In C/C++, those sets are  generated by  TBAA rules.  You could generate them however you want.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(Which in turn leads me to another question, that is, whether<br>
we are really trying to perform C/C++ alias analysis in a<br>
[language-neutral] codegen pass, but let's postpone this for<br>
later.)<br></blockquote><div><br></div><div>No, we are not trying to do so.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This consideration assumes that what the TBAA implementation<br>
actually returns as a result is orthogonal to the<br>
Must/No/MayAlias set, </blockquote><div><br></div><div>No, it is exactly a noalias set.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
The latter combination is what I would expect for illegal type<br>
puns, for whatever definition of "illegal". Note that for such<br>
cases we currently get MustAlias from BasicAA and NoAlias from<br>
TBAA.</blockquote><div><br></div><div>This is, IMHO, very very broken and should be fixed in clang.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> In some comments this is considered okay whereas I have to<br>
admit that I don't understand how that may possibly be okay,<br>
meaning it's hard to imagine how a pair of accesses can be<br>
aliasing and non-aliasing at the same time.</blockquote><div><br></div><div>Note that it will always be the case</div><div>It is entirely possible for one alias analysis to say must alias, and another to say no-alias, depending on the source of the info.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> To me it appears<br>
like that the root cause if this inconsistency is not that any of<br>
these analyses is not correct, but that we are trying to<br>
represent their responses in an inadequate form and we are trying<br>
to use BasicAA as a faster replacement for TBAA in simple cases.<br></blockquote><div><br></div><div>I don't really see this at all.</div><div><br></div><div>THe use of BasicAA to go with TBAA is, IMHO, just broken.</div><div>it's not trying to be faster, it's doing it for correctness.</div><div><br></div></div></div></div>