<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 11/29/21 10:19 AM, Matt Arsenault
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:51758147-9BE8-45F5-9EA5-56CD2D9E6739@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div><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><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>My counter proposal would be: use an addrspacecast for the cast.
Have GVN insert an addrspacecast instead of ptrtoint/inttoptr. <br>
</p>
<p>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>
</p>
<p>(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>
</p>
<p>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>
</p>
<p>Philip<br>
</p>
<p><br>
</p>
</body>
</html>