<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 Dec 21, 2018, at 12:07 AM, Adam Nemet 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=""><div dir="ltr" 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 class="Apple-interchange-newline"><br class="">On Dec 19, 2018, at 3:08 PM, Simon Moll <<a href="mailto:moll@cs.uni-saarland.de" class="">moll@cs.uni-saarland.de</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class=""><span class="">Hi,</span><br class=""><span class=""></span><br class=""><span class="">On 12/19/18 11:21 PM, David Greene via llvm-dev wrote:</span><br class=""><blockquote type="cite" class=""><span class="">Adam Nemet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> writes:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> I spent some time chatting with Adam about this and have a better</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> understanding of his concerns here. It seems to me that if having</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> masking intrinsics is the long-term solution we want, we should do</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> that now (for add and sub) rather than building arbitrary matrix</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> layout info into intrinsics, since a mask has all the information</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> that we actually need.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I think that sounds like a reasonable compromise. We already have</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">masked load/store intrinsics so adding add and sub just follows that</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">precedent. If the decision is made to move masking to the core</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">operations, the new intrinsics would just move as well.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class="">How will existing passes be taught about the new intrinsics? For</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">example, what would have to be done to instcombine to teach it about</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">these intrinsics? Let's suppose every existing operation had an</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">equivalent masked intrinsic. Would it be easier to teach all of the</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">passes about them or would it be easier to teach the passes about a mask</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">operand on the existing Instructions? Would it be easier to teach isel</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">about all the intrinsics or would it be easier to teach isel about a</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">mask operand?</span><br class=""></blockquote><span class=""></span><br class=""><span class="">Consider that over night we introduce optional mask parameters to vector instructions. Then, since you can not safely ignore the mask, every transformation and analysis that is somehow concerned with vector instructions is potentially broken and needs to be fixed.</span><br class=""><span class=""></span><br class=""><span class="">If you go with masking intrinsics, and set the attributes right, it is clear that transformations won't break your code and you will need to teach InstCombine, DAGCombiner, etc that a `masked.fadd` is just an `fadd` with a mask. However, this gives you the opportunity to "re-enable" one optimization add a time each time making sure that the mask is handled correctly. In case of InstCombine, the vector instruction patterns transfer to mask intrinsics: if all mask intrinsics in the pattern have the same mask parameter you can apply the transformation, the resulting mask intrinsics will again take the same mask parameter.</span><br class=""><span class=""></span><br class=""><span class="">Also, this need not be a hard transition from vector instructions to masking intrinsics.. you can add new types of masking intrinsics in batches along with the required transformations. Masking intrinsics and vector instruction can live side by side (as they do today, anyway).</span><br class=""></div></blockquote><div 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 class=""></div><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="">+1</span><div 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 class=""></div><div 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="">Also this thread is getting off-topic. It would probably be best to continue the discussion about the masked-intrinsic transition strategy under <a href="https://reviews.llvm.org/D53613" class="">https://reviews.llvm.org/D53613</a>.</div></div></blockquote><div><br class=""></div>I agree. The thread started to lose focus. It seems all that is needed to get this going on open source is get into the pragmatics mind set like Chris said and “just” agree on a decision on the sticking question like >you had suggested earlier.</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">My sense is that this info is important for your lowering, and your approach of using dataflow analysis to recover this will fail in some cases.</div></div></blockquote></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><br class=""></div></div></blockquote></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">Since layout and padding information is important, it seems most logical to put this into the type. Doing so would make it available in all these places.</div></div></blockquote></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><br class=""></div></div></blockquote></div><div><blockquote type="cite" class=""><div dir="ltr" class="">That said, I still don’t really understand why you *need* it.</div></blockquote></div><div><div class=""><br class=""></div></div><div><div class="">>This seems like the main sticking point so let’s close on this first and see if my answers above are satisfying.</div></div><div><blockquote type="cite" class=""><div class=""><div 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 class=""></div></div></blockquote></div><div><br class=""></div></blockquote><div class="">The rest will follow once the learning and iteration starts. </div><br class=""><div><blockquote type="cite" class=""><div 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 class=""><blockquote type="cite" class=""><div dir="ltr" class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">I honestly don't know the answers to these questions. But I think they</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">are important to consider, especially if intrinsics are seen as a bridge</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">to first-class IR support for masking.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">I think its sensible to use masking intrinsics (or EVL<span class="Apple-converted-space"> </span><a href="https://reviews.llvm.org/D53613" class="">https://reviews.llvm.org/D53613</a>) on IR level and masked SD nodes in the backend. However, i agree that intrinsics should just be a bridge to native support mid term.</span><br class=""><span class=""></span><br class=""><span class="">- Simon</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class=""> -David</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">LLVM Developers mailing list</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><br class=""></blockquote><span class=""></span><br class=""><span class="">--<span class="Apple-converted-space"> </span></span><br class=""><span class=""></span><br class=""><span class="">Simon Moll</span><br class=""><span class="">Researcher / PhD Student</span><br class=""><span class=""></span><br class=""><span class="">Compiler Design Lab (Prof. Hack)</span><br class=""><span class="">Saarland University, Computer Science</span><br class=""><span class="">Building E1.3, Room 4.31</span><br class=""><span class=""></span><br class=""><span class="">Tel. +49 (0)681 302-57521 :<span class="Apple-converted-space"> </span><a href="mailto:moll@cs.uni-saarland.de" class="">moll@cs.uni-saarland.de</a></span><br class=""><span class="">Fax. +49 (0)681 302-3065 :<span class="Apple-converted-space"> </span><a href="http://compilers.cs.uni-saarland.de/people/moll" class="">http://compilers.cs.uni-saarland.de/people/moll</a></span><br class=""><span class=""></span><br class=""></div></blockquote></div><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="">_______________________________________________</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=""><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="">LLVM Developers mailing list</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=""><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=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a></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=""><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=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span></blockquote></div><br class=""></body></html>