<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 12:02 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTVhUFRqtWFOLr-d0E1ra+HQ0XArjGq+_AH-HWbf1VNXmw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>I do not believe the current proposal will
solve all of those cases, particularly when the
fields are the same type and structures are
compatible but they cannot overlap in C/C++
anyway.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<div>One of the threads is titled "<span
style="font-size:inherit;font-weight:inherit">[PATCH]
D20665: Claim NoAlias if two GEPs index different fields
of the same struct"</span></div>
<div><br>
</div>
<div>For example, given<br>
<span style="font-size:12.8px">struct {</span><br
style="font-size:12.8px">
<span style="font-size:12.8px"> int arr_a[2];</span><br
style="font-size:12.8px">
<span style="font-size:12.8px"> int arr_b[2];</span><br
style="font-size:12.8px">
<span style="font-size:12.8px">};</span></div>
<div>assume you cannot see the original allocation site.<br>
</div>
<div>in llvm ir gep(arr_b, -1) is legally an access to
arr_a[1].</div>
<div>You can use -1 even though it's going to be a pointer
to [2 x i32].</div>
<div>Thus, you can't even tell that gep(arr_a, 0) and
gep(arr_b, -1) do not overlap without being able to know
*something* about the layout of fields in the structure
you are talking about.</div>
<div><br>
</div>
<div>I'd start with: It should not require tbaa to determine
that loads from geps that arr_a and arr_b cannot overlap.
It is true regardless of the types involved.</div>
<div><br>
</div>
<div>In terms of "who cares", Google definitely compiles
with -fno-strict-aliasing (because third party packages
are still not clean enough), and last i looked, Apple did
the same (but i admittedly have not kept up).</div>
</div>
</div>
</div>
</blockquote>
<br>
We definitely also have code that we compile that way as well. As it
turns out, this is my motivation for developing the type sanitizer
(so we have some tool that users can employ to clean up this kind of
code). Patches have been posted for review.<br>
<br>
<blockquote
cite="mid:CAF4BwTVhUFRqtWFOLr-d0E1ra+HQ0XArjGq+_AH-HWbf1VNXmw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div>GCC can definitely disambiguate field accesses (through
points-to and otherwise) better than LLVM in a situation
where strict aliasing is off.</div>
<div><br>
</div>
<div>As an aside, i also can't build a sane field-sensitive
points-to on our current type system, because the types
and structures are already meaningless (and we are busy
making it weaker, too).</div>
<div>I don't think we are going to want to tie
field-sensitive points-to to TBAA (you definitely want to
be able to run the former without the latter), but right
now that is the only metadata you can use.</div>
</div>
</div>
</div>
</blockquote>
<br>
This also brings up a good point. Even if we use the same metadata
for both type and field analysis, I don't see why we can't disable
the type portions without disabling the field analysis (essentially
by emitting everything as one universally-aliasing type). Maybe we
should do that for -fno-strict-aliasing?<br>
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote
cite="mid:CAF4BwTVhUFRqtWFOLr-d0E1ra+HQ0XArjGq+_AH-HWbf1VNXmw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Finally, the merging of TBAA is definitely going to be
more conservative than the merging of field offset info:
If we merge a load of an int and a float, we will, IIRC,
go to the nearest common ancestor in TBAA. The field
offset info may actually still be identical between the
two, but we will lose it by creating/or going to the
common ancestor.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
</div>
<br>
</div>
</div>
</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>