<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 14, 2021 at 7:34 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"><br>
<br>
On 13 Jun 2021, at 11:26, Ralf Jung wrote:<br>
<br>
> Hi Johannes,<br>
><br>
>>> I think Joshua gave a very nice motivation already.<br>
>><br>
>> I don't dispute that but I am still not understanding the need for <br>
>> bytes. None of the examples I have seen so far<br>
>> clearly made the point that it is the byte types that provide a <br>
>> substantial benefit. The AA example below does neither.<br>
><br>
> I hope <br>
> <<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-June/151110.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2021-June/151110.html</a>> <br>
> makes a convincing case that under the current semantics, when one <br>
> does an "i64" load of a value that was stored at pointer type, we have <br>
> to say that this load returns poison. In particular, saying that this <br>
> implicitly performs a "ptrtoint" is inconsistent with optimizations <br>
> that are probably too important to be changed to accommodate this <br>
> implicit "ptrtoint".<br>
<br>
I think it is fact rather obvious that, if this optimization as <br>
currently written is indeed in conflict with the current semantics, it <br>
is the optimization that will have to give.  If the optimization is too <br>
important for performance to give up entirely, we will simply have to <br>
find some more restricted pattern that wee can still soundly optimize.<br></blockquote><div><br></div><div>I tend to agree. I don't think Ralf's example alone is convincing evidence that pointer-load of integer-store must be poison, i.e. memory must be typed.</div><div><br></div><div>FWIW, the least important optimization in that example's chain, and the one that is most obviously incorrect in an untyped memory world, is eliminating a store of a previously loaded value. How much would we actually lose if we disable this particular optimization? Note that this is only a small special case of dead store elimination. The more common case where there are two stores to memory in a row, and the first one is eliminated, is still correct.</div><div><br></div><div>Cheers,</div><div>Nicolai</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Perhaps the clearest reason is that, if we did declare that integer <br>
types cannot carry pointers and so introduced byte types that could, C <br>
frontends would have to switch to byte types for their integer types, <br>
and so we would immediately lose this supposedly important optimization <br>
for C-like languages, and so, since optimizing C is very important, we <br>
would immediately need to find some restricted pattern under which we <br>
could soundly apply this optimization to byte types.  That’s assuming <br>
that this optimization is actually significant, of course.<br>
<br>
John.<br>
_______________________________________________<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"><br>-- <br><div dir="ltr" class="gmail_signature">Lerne, wie die Welt wirklich ist,<br>aber vergiss niemals, wie sie sein sollte.</div></div>