<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi,<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 04/06/2021 16:24, George Mitenkov
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAG8Odm=fhq7LfFbOuT4x7WDCBXH=muYzxMv=bVM-TG0HRZfHFA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><span
id="gmail-docs-internal-guid-ec050142-7fff-10f3-b533-a9ba2e107dc6"
style="color:rgb(0,0,0)">
<ol style="margin-top:0px;margin-bottom:0px" start="2">
<li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;font-variant-ligatures:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-variant-ligatures:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">When copying pointers as bytes implicit pointer-to-integer casts are avoided.The current setting of performing a memcpy using i8s leads to miscompilations (example: bug report </span><a href="https://bugs.llvm.org/show_bug.cgi?id=37469" style="text-decoration:none" moz-do-not-send="true"><span style="font-size:11pt;font-variant-ligatures:normal;font-variant-east-asian:normal;text-decoration:underline;text-decoration-skip:none;vertical-align:baseline;white-space:pre-wrap">37469</span></a><span style="font-size:11pt;font-variant-ligatures:normal;font-variant-east-asian:normal;vertical-align:ba
seline;white-space:pre-wrap">) and is bad for alias analysis.</span></p></li>
</ol>
</span></div>
</div>
</blockquote>
<p>While trying to understand what exactly is going wrong in this
bug I think I stumbled upon incomplete documentation. At
<a class="moz-txt-link-freetext" href="https://llvm.org/docs/LangRef.html#pointeraliasing">https://llvm.org/docs/LangRef.html#pointeraliasing</a> it is
documented that</p>
<ul>
<li>A memory access must be done through a pointer associated with
the address range.</li>
<li>A pointer value is associated with the addresses associated
with any
value it is based on.</li>
<li>A pointer value formed by an instruction is based on another
pointer value the instruction is getelementptr, bitcast, or
inttoptr.</li>
</ul>
<p>What is not mentioned is what a pointer value formed by a load
instruction is based on. If a pointer value formed by a load
instruction is not associated with any address range, then it
cannot be used to load or store <i>any</i> value. Clearly that is
not wanted.</p>
<p>If memory is completely untyped, then a load of a pointer value
needs to be equivalent to a load of an integer value followed by
inttoptr. In that model, it is not possible to replace a load of a
pointer value by a previously stored value, it is only possible to
replace it by inttoptr(ptrtoint(previously stored value)). In that
model, the problem is that LLVM does replace a load of a pointer
value by a previously stored value, and the bug can be fixed (at a
cost of reduced optimisations of other code) by making sure to
insert ptrtoint and inttoptr as needed, including for any pointer
members of structs etc.</p>
<p>Your proposal is based on an interpretation of the problem using
a memory model where memory is not completely untyped. In your
memory model, what address range is a pointer value that came from
a load instruction associated with?</p>
<p>Cheers,<br>
Harald van Dijk<br>
</p>
</body>
</html>