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