<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 6/6/21 00:26, Chris Lattner via
cfe-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E94F34D6-7232-4883-AEA6-1236E6347912@nondot.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
On Jun 4, 2021, at 11:25 AM, John McCall via cfe-dev <<a
href="mailto:cfe-dev@lists.llvm.org"
class="moz-txt-link-freetext" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
wrote:<span style="font-family: sans-serif;" class="">On 4 Jun
2021, at 11:24, George Mitenkov wrote:</span>
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div style="font-family:sans-serif" class="">
<div style="white-space:normal" class="">
<blockquote style="border-left:2px solid #3983C4;
color:#3983C4; margin:0 0 5px; padding-left:5px"
class="">
<p dir="auto" class="">Hi all,<br class="">
<br class="">
Together with Nuno Lopes and Juneyoung Lee we
propose to add a new byte<br class="">
type to LLVM to fix miscompilations due to load
type punning. Please see<br class="">
the proposal below. It would be great to hear the<br
class="">
feedback/comments/suggestions!<br class="">
<br class="">
<br class="">
Motivation<br class="">
==========<br class="">
<br class="">
char and unsigned char are considered to be
universal holders in C. They<br class="">
can access raw memory and are used to implement
memcpy. i8 is the LLVM’s<br class="">
counterpart but it does not have such semantics,
which is also not<br class="">
desirable as it would disable many optimizations.</p>
</blockquote>
</div>
<div style="white-space:normal" class="">
<p dir="auto" class="">I don’t believe this is
correct. LLVM does not have an innate<br class="">
concept of typed memory. The type of a global or
local allocation<br class="">
is just a roundabout way of giving it a size and
default alignment,<br class="">
and similarly the type of a load or store just
determines the width<br class="">
and default alignment of the access. There are no
restrictions on<br class="">
what types can be used to load or store from certain
objects.</p>
<p dir="auto" class="">C-style type aliasing
restrictions are imposed using <code class="">tbaa</code><br
class="">
metadata, which are unrelated to the IR type of the
access.</p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>I completely agree with John. “i8” in LLVM doesn’t carry any
implications about aliasing (in fact, LLVM pointers are going
towards being typeless). Any such thing occurs at the accesses,
and are part of TBAA.</div>
<div><br class="">
</div>
<div>I’m opposed to adding a byte type to LLVM, as such semantic
carrying types are entirely unprecedented, and would add
tremendous complexity to the entire system.</div>
<div><br class="">
</div>
<div>-Chris</div>
</blockquote>
<p><br>
</p>
<p>I'll take this opportunity to point out that, at least
historically, the reason why a desire to optimize around ptrtoint
keeps resurfacing is because:</p>
<p> 1. Common optimizations introduce them into code that did not
otherwise have them (SROA, for example, see convertValue in
SROA.cpp).</p>
<p> 2. They're generated by some of the ABI code for argument
passing (see clang/lib/CodeGen/TargetInfo.cpp).</p>
<p> 3. They're present in certain performance-sensitive code idioms
(see, for example, ADT/PointerIntPair.h).<br>
</p>
<p>It seems to me that, if there's design work to do in this area,
one should consider addressing these now-long-standing issues
where we introduce ptrtoint by replacing this mechanism with some
other one.<br>
</p>
<p> -Hal<br>
</p>
<blockquote type="cite"
cite="mid:E94F34D6-7232-4883-AEA6-1236E6347912@nondot.org"><br
class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
</body>
</html>