<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 */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">In case anyone reading this thread is unaware, there is currently a proposal before the C standards committee that goes into more details on a future provenance model for C:
<a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf</a>. It actually details a few different provenance models, especially several variations on integers-do-not-have-provenance, mainly
around what provenance is reconstructed on an inttoptr cast. While I’m not on the standards committee, I believe that something along the lines of this proposal will become the official C provenance rules.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While LLVM isn’t required to adopt C rules wholesale, the basic form of the proposal already matches applied LLVM semantics better than our own language reference (we do not consider integers to carry provenance). There are several points
in the proposal where extra annotations are suggested to effect various provenance properties (e.g., the ability to write word-level memcpy), and offhand, it looks like the byte proposal would be a viable vehicle for those extra annotations, although I’m not
entirely persuaded that it’s the best vehicle.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>John McCall via llvm-dev<br>
<b>Sent:</b> Monday, June 14, 2021 12:08<br>
<b>To:</b> Ralf Jung <jung@mpi-sws.org><br>
<b>Cc:</b> llvm-dev@lists.llvm.org; cfe-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Introducing a byte type to LLVM<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p><span style="font-family:"Arial",sans-serif">On 14 Jun 2021, at 7:04, Ralf Jung wrote:<o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #3983C4 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<p><span style="font-family:"Arial",sans-serif;color:#3983C4">Hi,<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #7CBF0C 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<blockquote style="border:none;border-left:solid #7CBF0C 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<blockquote style="border:none;border-left:solid #7CBF0C 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<p><span style="font-family:"Arial",sans-serif;color:#7CBF0C">I don't dispute that but I am still not understanding the need for bytes. None of the examples I have seen so far<br>
clearly made the point that it is the byte types that provide a substantial benefit. The AA example below does neither.<o:p></o:p></span></p>
</blockquote>
<p><span style="font-family:"Arial",sans-serif;color:#7CBF0C">I hope <<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-June/151110.html">https://lists.llvm.org/pipermail/llvm-dev/2021-June/151110.html</a>> makes a convincing case that under the current
semantics, when one does an "i64" load of a value that was stored at pointer type, we have to say that this load returns poison. In particular, saying that this implicitly performs a "ptrtoint" is inconsistent with optimizations that are probably too important
to be changed to accommodate this implicit "ptrtoint".<o:p></o:p></span></p>
</blockquote>
<p><span style="font-family:"Arial",sans-serif;color:#7CBF0C">I think it is fact rather obvious that, if this optimization as currently written is indeed in conflict with the current semantics, it is the optimization that will have to give. If the optimization
is too important for performance to give up entirely, we will simply have to find some more restricted pattern that wee can still soundly optimize.<o:p></o:p></span></p>
</blockquote>
<p><span style="font-family:"Arial",sans-serif;color:#3983C4">That is certainly a reasonable approach.<br>
However, judging from how reluctant LLVM is to remove optimizations that are much more convincingly wrong [1], my impression was that it is easier to complicate the semantics than to remove an optimization that LLVM already performs.<br>
<br>
[1]: <a href="https://bugs.llvm.org/show_bug.cgi?id=34548">https://bugs.llvm.org/show_bug.cgi?id=34548</a>,<br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=35229">https://bugs.llvm.org/show_bug.cgi?id=35229</a>;<br>
see <a href="https://www.ralfj.de/blog/2020/12/14/provenance.html">https://www.ralfj.de/blog/2020/12/14/provenance.html</a> for a<br>
more detailed explanation<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #7CBF0C 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<p><span style="font-family:"Arial",sans-serif;color:#7CBF0C">Perhaps the clearest reason is that, if we did declare that integer types cannot carry pointers and so introduced byte types that could, C frontends would have to switch to byte types for their integer
types, and so we would immediately lose this supposedly important optimization for C-like languages, and so, since optimizing C is very important, we would immediately need to find some restricted pattern under which we could soundly apply this optimization
to byte types. That’s assuming that this optimization is actually significant, of course.<o:p></o:p></span></p>
</blockquote>
<p><span style="font-family:"Arial",sans-serif;color:#3983C4">At least C with strict aliasing enabled (i.e., standard C) only needs to use the byte type for "(un)signed char". The other integer types remain unaffected. There is no arithmetic on these types
("char + char" is subject to integer promotion), so the IR overhead would consist in a few "bytecast" instructions next to / replacing the existing sign extensions that convert "char" to "int" before performing the arithmetic.<o:p></o:p></span></p>
</blockquote>
</div>
<div>
<p><span style="font-family:"Arial",sans-serif">The semantics you seem to want are that LLVM’s integer types cannot carry information from pointers. But I can cast a pointer to an integer in C and vice-versa, and compilers have de facto defined the behavior
of subsequent operations like breaking the integer up (and then putting it back together), adding numbers to it, and so on. So no, as a C compiler writer, I do not have a choice; I will have to use a type that can validly carry pointer information for integers
in C.<o:p></o:p></span></p>
<p><span style="font-family:"Arial",sans-serif">Since you seem to find this sort of thing compelling, please note that even a simple assignment like
</span><code><span style="font-size:10.0pt">char c2 = c1</span></code><span style="font-family:"Arial",sans-serif"> technically promotes through
</span><code><span style="font-size:10.0pt">int</span></code><span style="font-family:"Arial",sans-serif"> in C, and so
</span><code><span style="font-size:10.0pt">int</span></code><span style="font-family:"Arial",sans-serif"> must be able to carry pointer information if
</span><code><span style="font-size:10.0pt">char</span></code><span style="font-family:"Arial",sans-serif"> can.<o:p></o:p></span></p>
<p><span style="font-family:"Arial",sans-serif">John.<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>