<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
code
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><div><div><p style='margin-left:5.25pt'><span style='font-family:"Arial",sans-serif'>On 4 Jun 2021, at 11:24, George Mitenkov wrote:<o:p></o:p></span></p></div><div><blockquote style='border:none;border-left:solid #3983C4 1.5pt;padding:0cm 0cm 0cm 4.0pt;margin-left:0cm;margin-right:0cm;margin-bottom:3.75pt'><p style='margin-left:5.25pt'><span style='font-family:"Arial",sans-serif;color:#3983C4'>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.<o:p></o:p></span></p></blockquote></div><div><p style='margin-left:5.25pt'><span style='font-family:"Arial",sans-serif'>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.<o:p></o:p></span></p><p style='margin-left:5.25pt'><span style='font-family:"Arial",sans-serif'>C-style type aliasing restrictions are imposed using </span><code><span style='font-size:10.0pt'>tbaa</span></code><span style='font-family:"Arial",sans-serif'><br>metadata, which are unrelated to the IR type of the access.<o:p></o:p></span></p><p style='margin-left:5.25pt'><span style='font-family:"Arial",sans-serif'><o:p> </o:p></span></p><p style='margin:0cm'>It<span style='font-family:"Times New Roman",serif'>’</span>s debatable whether LLVM considers memory to be typed or not. If we don<span style='font-family:"Times New Roman",serif'>’</span>t consider memory to be typed, then *<b>all</b>* integer load operations have to be considered as potentially escaping pointers. Example:<br>store i32* %p, i32** %q<br>%q2 = bitcast i32** %q to i64*<br>%v = load i64* %q2<br><br>This program stores a pointer and then loads it back as an integer. So there<span style='font-family:"Times New Roman",serif'>’</span>s an implicit pointer-to-integer cast, which escapes the pointer. If we allow this situation to happen, then the alias analysis code is broken, as well as several optimizations. LLVM doesn<span style='font-family:"Times New Roman",serif'>’</span>t consider loads as potential pointer escape sites. It would probably be a disaster (performance wise) if it did!<o:p></o:p></p><p style='margin:0cm'><o:p> </o:p></p><p style='margin:0cm'>The introduction of the byte type allow us to make all pointer <-> integer casts explicit, so that we don<span style='font-family:"Times New Roman",serif'>’</span>t have to make all integer loads as escaping. It also allow us to say that LLVM optimizations are correct, and we <span style='font-family:"Times New Roman",serif'>“</span>just<span style='font-family:"Times New Roman",serif'>”</span> need to create a few new optimization to get rid of the extra bytecast instructions when they are provably not needed.<o:p></o:p></p><p style='margin:0cm'>TBAA is unrelated to the problem we are trying to solve here.<o:p></o:p></p><p style='margin:0cm'><o:p> </o:p></p><p style='margin:0cm'>Nuno<o:p></o:p></p></div></div></div></body></html>