<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 08/20/2017 11:22 AM, Daniel Berlin
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTXsNXLBj894eKwfDnUCG9rCLPSETqLr_suz8J5stjBGAg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Sorry, hit send early.
<div><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Aug 20, 2017 at 9:16 AM,
Daniel Berlin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Sun, Aug
20, 2017 at 8:54 AM, Ivan A. Kosarev via
llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Hello Daniel,<span><br>
<br>
> The problem with the way you are trying
to show this is that<br>
> there are many ways to prove no-alias,
and TBAA is one of them.<br>
> The reason i stare at dump files and
debug info is precisely to<br>
> separate the TBAA portion from the
rest.<br>
<br>
</span>
Makes sense to me. However, for a translation
unit like this:<br>
<br>
struct BUF1 { ... };<br>
struct BUF2 { ... };<span><br>
<br>
int foo(int n, struct BUF1* p, struct
BUF2* q) {<br>
for (int i = 0; i < n; i++)<br>
p->b1 += q->b2;<br>
return 0;<br>
}<br>
<br>
</span>
I think we can be sure there are no ways for
the compiler to know that these two accesses
do not overlap, except TBAA.</blockquote>
<div><br>
</div>
</span>
<div>This is definitely false in general.</div>
<div>Again, speaking about GCC, the logic for
whether fields can be accessed is separate from
the logic about whether TBAA says fields can be
accessed.</div>
<div>In some cases the flags to control the logic
are both controlled by fstrict-aliasing, but are
unrelated to tbaa. <br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Our current TBAA combines these two things (field-offset-based
determinations and strictly-type-based rules) into what we call
TBAA. This proposal does likewise. Are there advantages to splitting
them that we should consider?<br>
<br>
Thanks again,<br>
Hal <br>
<br>
<blockquote
cite="mid:CAF4BwTXsNXLBj894eKwfDnUCG9rCLPSETqLr_suz8J5stjBGAg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Even if you have tried to place the fields at
the same offset, as you have, whether it can
disambiguate the accesses can depend on more
than just TBAA, including alignment rules, etc.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You definitely may be able to come up with examples
where only tbaa *should* be active, but i don't think
it's really a safe way to go about testing assumptions
about TBAA.</div>
<div>For example, it also assumes no bugs in the other
methods of analysis, which is defintitely not a safe
assumption :)</div>
<div><br>
</div>
<div>If you only care about the *end result* (IE whether
it's allow to say the accesses overlap) it is generally
going to be okay, but again, this assumes no bug in any
implementation</div>
<div><br>
</div>
<div>If you want to test tbaa specific things for real,
you'd have to print the tbaa trees and results as gcc
sees them, for example.</div>
<div>That's really the only way to be sure.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>