<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br>On Dec 19, 2018, at 3:08 PM, Simon Moll <<a href="mailto:moll@cs.uni-saarland.de">moll@cs.uni-saarland.de</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>Hi,</span><br><span></span><br><span>On 12/19/18 11:21 PM, David Greene via llvm-dev wrote:</span><br><blockquote type="cite"><span>Adam Nemet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span> I spent some time chatting with Adam about this and have a better</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> understanding of his concerns here. It seems to me that if having</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> masking intrinsics is the long-term solution we want, we should do</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> that now (for add and sub) rather than building arbitrary matrix</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> layout info into intrinsics, since a mask has all the information</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> that we actually need.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think that sounds like a reasonable compromise. We already have</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>masked load/store intrinsics so adding add and sub just follows that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>precedent. If the decision is made to move masking to the core</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>operations, the new intrinsics would just move as well.</span><br></blockquote></blockquote><blockquote type="cite"><span>How will existing passes be taught about the new intrinsics? For</span><br></blockquote><blockquote type="cite"><span>example, what would have to be done to instcombine to teach it about</span><br></blockquote><blockquote type="cite"><span>these intrinsics? Let's suppose every existing operation had an</span><br></blockquote><blockquote type="cite"><span>equivalent masked intrinsic. Would it be easier to teach all of the</span><br></blockquote><blockquote type="cite"><span>passes about them or would it be easier to teach the passes about a mask</span><br></blockquote><blockquote type="cite"><span>operand on the existing Instructions? Would it be easier to teach isel</span><br></blockquote><blockquote type="cite"><span>about all the intrinsics or would it be easier to teach isel about a</span><br></blockquote><blockquote type="cite"><span>mask operand?</span><br></blockquote><span></span><br><span>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><span></span><br><span>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><span></span><br><span>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></div></blockquote><div><br></div>+1<div><br></div><div>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">https://reviews.llvm.org/D53613</a>.</div><div><br></div><div>Adam</div><div><br><blockquote type="cite"><div dir="ltr"><span></span><br><blockquote type="cite"><span>I honestly don't know the answers to these questions. But I think they</span><br></blockquote><blockquote type="cite"><span>are important to consider, especially if intrinsics are seen as a bridge</span><br></blockquote><blockquote type="cite"><span>to first-class IR support for masking.</span><br></blockquote><span></span><br><span>I think its sensible to use masking intrinsics (or EVL <a href="https://reviews.llvm.org/D53613">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><span></span><br><span>- Simon</span><br><span></span><br><blockquote type="cite"><span> -David</span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>LLVM Developers mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></span><br></blockquote><blockquote type="cite"><span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><br></blockquote><span></span><br><span>-- </span><br><span></span><br><span>Simon Moll</span><br><span>Researcher / PhD Student</span><br><span></span><br><span>Compiler Design Lab (Prof. Hack)</span><br><span>Saarland University, Computer Science</span><br><span>Building E1.3, Room 4.31</span><br><span></span><br><span>Tel. +49 (0)681 302-57521 : <a href="mailto:moll@cs.uni-saarland.de">moll@cs.uni-saarland.de</a></span><br><span>Fax. +49 (0)681 302-3065 : <a href="http://compilers.cs.uni-saarland.de/people/moll">http://compilers.cs.uni-saarland.de/people/moll</a></span><br><span></span><br></div></blockquote></div></body></html>