<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 May 5, 2020, at 14:14, Amara Emerson <<a href="mailto:aemerson@apple.com" class="">aemerson@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="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; float: none; display: inline !important;" class="">I don’t think it was me who said that but it’s a good point.</span><br style="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=""><br style="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=""><span style="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; float: none; display: inline !important;" class="">I see no good reason not to re-use the existing IR instructions for computation on BFloat, given that we do so for other uncommon FP formats as well. Which I think in turn leaves us with little choice but to mirror the IR here (adding separate opcodes for this case just seems wrong).</span></div></blockquote></div><br class=""><div class="">I thought about this a bit and I think adding separate LLTs is probably the right approach. We were ignoring the existence of ppcf128 anyway, so bfloat16 doesn’t really introduce a new issue. However, I do want to deviate from the IR and SelectionDAG’s treatment of integer vs. FP operations to preserve the current property GlobalISel has where integer operations are allowed to freely operate directly on FP values. As long as I’m not required to insert bitcasts to/from integer LLTs just to operate on the bits of an FP value, I’m OK with it. We would only consider these different types in floating point contexts, and they would implicitly behave as the equivalent sized integers elsewhere. The current intermediate bitcasts needed in various FP legalization code are quite annoying, and they’ve always been an obstacle to some combines.</div><div class=""><br class=""></div><div class="">-Matt</div></body></html>