<div dir="ltr"><div dir="ltr"><div class="gmail_attr">On Tue, Jun 15, 2021 at 1:08 AM John McCall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div><blockquote style="border-left:2px solid rgb(57,131,196);color:rgb(57,131,196);margin:0px 0px 5px;padding-left:5px">
</blockquote></div>
<div>
<p dir="auto">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.</p></div></div></div></blockquote>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">int->ptr cast can reconstruct the pointer information, so making integer types not carry pointer information does not necessarily mean that dereferencing a pointer casted from integer is UB.</p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">For example, the definition of cast_ival_to_ptrval at the n2676 proposal shows that a pointer's provenance is reconstructed from an integer.</p>
<div><span style="font-family:"Helvetica Neue";font-size:13px">(Whether n2676's </span>cast_ival_to_ptrval<span style="font-size:13px;font-family:"Helvetica Neue""> can be also used for LLVM's inttoptr semantics is a different question, though)</span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:sans-serif">
<p dir="auto">Since you seem to find this sort of thing compelling, please note that even a simple assignment like <code>char c2 = c1</code> technically promotes through <code>int</code> in C, and so <code>int</code> must be able to carry pointer information if <code>char</code> can.</p></div></blockquote>
<div><span style="font-family:"Helvetica Neue";font-size:13px">IIUC integer promotion is done when it is used as an operand of arithmetic ops or switch's condition, so I think </span>assignment operation is okay.</div><div><br></div><div>Juneyoung </div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 15, 2021 at 1:08 AM John McCall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 14 Jun 2021, at 7:04, Ralf Jung wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid rgb(57,131,196);color:rgb(57,131,196);margin:0px 0px 5px;padding-left:5px"><p dir="auto">Hi,<br>
</p>
<blockquote style="border-left:2px solid rgb(124,191,12);color:rgb(124,191,12);margin:0px 0px 5px;padding-left:5px"><blockquote style="border-left:2px solid rgb(124,191,12);color:rgb(124,191,12);margin:0px 0px 5px;padding-left:5px"><blockquote style="border-left:2px solid rgb(124,191,12);color:rgb(124,191,12);margin:0px 0px 5px;padding-left:5px"><p dir="auto">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.</p>
</blockquote><p dir="auto">I hope <<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-June/151110.html" target="_blank">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".</p>
</blockquote><p dir="auto">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.</p>
</blockquote><p dir="auto">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" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=34548</a>,<br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=35229" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=35229</a>;<br>
see <a href="https://www.ralfj.de/blog/2020/12/14/provenance.html" target="_blank">https://www.ralfj.de/blog/2020/12/14/provenance.html</a> for a<br>
more detailed explanation<br>
</p>
<blockquote style="border-left:2px solid rgb(124,191,12);color:rgb(124,191,12);margin:0px 0px 5px;padding-left:5px"><p dir="auto">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.</p>
</blockquote><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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.</p>
<p dir="auto">Since you seem to find this sort of thing compelling, please note that even a simple assignment like <code>char c2 = c1</code> technically promotes through <code>int</code> in C, and so <code>int</code> must be able to carry pointer information if <code>char</code> can.</p>
<p dir="auto">John.</p>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div></div>