<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Jun 4, 2021, at 11:25 AM, John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">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><br class=""></body></html>