<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=""><div class="">Matt: that’s fair. We’re generally apprehensive of option 2 as well.</div><div class=""><br class=""></div><div class="">Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader.</div><div class=""><br class=""></div><div class="">If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify that there’s no guarantee of correction codegen *solely* on the basis of int/fp type overloading for intrinsics. What do you think?</div><div class=""><br class=""></div><div class="">Amara</div><div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Mar 11, 2019, at 1:23 PM, Matt Arsenault <<a href="mailto:arsenm2@gmail.com" class="">arsenm2@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 11, 2019, at 3:30 PM, Amara Emerson 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 http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi GlobalISel interested parties,<div class=""><br class=""></div><div class="">A recent bug report (<a href="https://bugs.llvm.org/show_bug.cgi?id=40968" class="">https://bugs.llvm.org/show_bug.cgi?id=40968</a>) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose information during IR translation of type overloaded intrinsics.</div></div></div></div></blockquote></div><br class=""><div class="">I’m pretty strongly opposed to #2. I think the more relaxed type system is one of the advantages over SelectionDAG, and want to avoid the mess of bitcasts we have to insert now to satisfy the artificial type constraints. The original intrinsic seems misspecified to me, and should be spilt into separate FP/int versions.</div><div class=""><br class=""></div><div class="">-Matt</div></div></div></blockquote></div><br class=""></div></div></body></html>