<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 6/9/21 15:06, Philip Reames via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:75419c65-95f7-50f7-e3cf-800feccdbaf5@philipreames.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 6/5/21 9:26 PM, Chris Lattner via
llvm-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>
</blockquote>
<p>I agree with both John and Chris here.</p>
<p>I've read through the discussion in this thread, and have yet
to be convinced there is a problem, much less than this is a
good solution. I'm open to being convinced of those two things,
but the writeup in this thread doesn't do it. There's snippet
of examples downthread which might be convincing, but there's
objections raised around language semantics which I find very
hard to follow. The fragmentation of the thread really doesn't
help. <br>
</p>
<p>I would suggest the OP take some of the motivating examples,
write up a web-page with the examples and their interpretation,
then revisit the topic. In particular, I strongly suggest
anticipating incorrect interpretation/objections and explicitly
addressing them.</p>
<p>I'll also note that the use of the term capture w.r.t a *load*
downthread makes absolutely no sense to me. Stores capture, not
loads. <br>
</p>
<p>Philip<br>
</p>
</blockquote>
<p><br>
</p>
<p>I agree.</p>
<p>Also, while there certainly is a problem combining GVN with our
use-def-chain-based pointer-aliasing/provenance semantics, it is
in no way clear to me how a byte type helps resolve that problem.</p>
<p> -Hal</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:75419c65-95f7-50f7-e3cf-800feccdbaf5@philipreames.com">
<p> </p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>