<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 4 Jun 2021, at 11:24, George Mitenkov wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #3983C4; color:#3983C4; margin:0 0 5px; padding-left:5px"><p dir="auto">Hi all,<br>
<br>
Together with Nuno Lopes and Juneyoung Lee we propose to add a new byte<br>
type to LLVM to fix miscompilations due to load type punning. Please see<br>
the proposal below. It would be great to hear the<br>
feedback/comments/suggestions!<br>
<br>
<br>
Motivation<br>
==========<br>
<br>
char and unsigned char are considered to be universal holders in C. They<br>
can access raw memory and are used to implement memcpy. i8 is the LLVM’s<br>
counterpart but it does not have such semantics, which is also not<br>
desirable as it would disable many optimizations.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I don’t believe this is correct. LLVM does not have an innate<br>
concept of typed memory. The type of a global or local allocation<br>
is just a roundabout way of giving it a size and default alignment,<br>
and similarly the type of a load or store just determines the width<br>
and default alignment of the access. There are no restrictions on<br>
what types can be used to load or store from certain objects.</p>
<p dir="auto">C-style type aliasing restrictions are imposed using <code>tbaa</code><br>
metadata, which are unrelated to the IR type of the access.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>