<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 29, 2021, at 13:28, Philip Reames <<a href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252" class="">
  
  <div class=""><p class=""><br class="">
    </p>
    <div class="moz-cite-prefix">On 11/29/21 10:19 AM, Matt Arsenault
      wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:51758147-9BE8-45F5-9EA5-56CD2D9E6739@gmail.com" class="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252" class="">
      <br class="">
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">On Nov 29, 2021, at 12:54, Philip Reames via
            llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <meta charset="UTF-8" class="">
            <div style="margin-top: 0px; margin-bottom: 0px;
              caret-color: rgb(0, 0, 0); font-family: Helvetica;
              font-size: 12px; font-style: normal; font-variant-caps:
              normal; font-weight: normal; letter-spacing: normal;
              text-align: start; text-indent: 0px; text-transform: none;
              white-space: normal; word-spacing: 0px;
              -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Strong -1 here.  This seems like an abuse of
              bitcast to avoid nailing down interfaces and semantics for
              restricted address space casts.  IMO, we should not accept
              the proposed IR change and should instead work on
              standardizing APIs/semantics for restricted
              addrspacecasts.  </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        I think you are misunderstanding the point of the change. The
        motivating example is specifically not an address space cast.
        The reason to do this is not to improve the optimization of
        no-op address space casts, although that is a potential side
        effect. The point is to give the IR a way to represent a cast we
        know is a no-op cast to represent type punning in the original
        program without resorting to ptrtoint/inttoptr. This is to avoid
        the pessimization of ptrtoint, not to make no-op addrspacecast
        optimizations better.</div>
    </blockquote><p class="">My counter proposal would be: use an addrspacecast for the cast. 
      Have GVN insert an addrspacecast instead of ptrtoint/inttoptr.  <br class="">
    </p><p class="">From GVNs perspective, type punning *implies* that the resulting
      addrspacecast must be mustalias.  It doesn't have to explicitly
      query anything to prove that.  One thing to highlight: Two
      pointers in different addrspaces can be mustalias *without*
      sharing the same bit pattern.  As a result, the GVN case implies
      mustalias, but *not* pointer equality.  <br class="">
    </p><p class="">(I forget where we stand on whether addrspacecast is allowed to
      fault.  If we allow faults, we need a semantic restriction on
      introducing the addrspacecast, but that's simply a target property
      check.  I vaguely think we don't allow addrspacecast to fault, and
      thus this aside is irrelevant.)<br class="">
    </p><p class="">For the nop case (e.g. where the bits are the same), add a TTI
      hook, and teach ComputeKnownBits and other analyzes to selectively
      look back through them.<br class="">
    </p></div></div></blockquote><div>This still forces adding more target information into places where it does not belong, Additionally, this is still no help if the given pair of address spaces is not a no-op. We would still have to fallback to the ptrtoint/inttoptr pair, so there’s still a semantic hole in the IR that requires introducing them</div><div><br class=""></div><div>-Matt</div></div><br class=""></body></html>