<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>