<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></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 12:54, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">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><div><br class=""></div><div>-Matt</div><br class=""></body></html>