<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 17, 2016, at 6:14 PM, Daniel Berlin 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" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 17, 2016 at 5:17 PM, Saito, Hideki via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<font face="Calibri" size="2" class=""><span style="font-size:11pt" class=""><span class="">
<div class=""><font color="#1F497D" class=""> </font></div>
<div class="">>What situations are they common in?</div>
<div class=""><font color="#1F497D" class=""> </font></div>
</span><div class=""><font color="#1F497D" class="">ICC Vectorizer made a paradigm shift a while ago.</font></div>
<div style="text-indent:36pt" class=""><font color="#1F497D" class="">If there aren’t a clear reason why something can’t be vectorized, we should try our best to vectorize.</font></div>
<div class=""><font color="#1F497D" class="">The rest is a performance modeling (and priority to implement) question, not a capability question.</font></div>
<div class=""><font color="#1F497D" class="">We believe this is a good paradigm to follow in a vectorizer development.</font></div></span></font></div></blockquote><div class=""><br class=""></div><div class="">In some sense, yes, but not at all possible costs.</div><div class="">There needs to be some actual motivating case to make it worth even writing the code for.</div></div></div></div></div></blockquote><div><br class=""></div>This paradigm can have far reaching consequences. The vectorizer is the performance cow to milk at the IR level. So under that paradigm - followed religiously - one would plug in any loop transformation, polyhedral or non-polyhedral etc cost models etc to morph code vectorizable. And when that is not sufficient one would probably start adding large numbers of run-time checks, multi-versioned code etc. This might be a good paradigm to follow from the peak performance angle, but not so from the compile-time or code size angle. It seems best to pursue a paradigm like this with a peak performance library rather than mainstream llvm.</div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><font face="Calibri" size="2" class=""><span style="font-size:11pt" class=""><div class=""><font color="#1F497D" class=""> It was a big departure from</font></div>
<div class=""><font color="#1F497D" class="">“vectorize when all things look nice to vectorizer”.</font></div></span></font></div></blockquote><div class=""><br class=""></div><div class="">These are not diametrically opposed.</div><div class=""><br class=""></div><div class="">I mean, it may be not worth the cost of mainintaing the *compiler code* to do o it.</div><div class="">This isn't the same as "when things look nice to the vectorizer", it's more "we're willing to vectorize whatever we can, as long as someone is going to actually use it".</div><div class=""><br class=""></div><div class="">Nobody has here provided a useful set of cases/applications/etc that suggests it should be done. I'm not saying there are none, i'm saying, literally, nobody has motivated this use case yet :)</div></div></div></div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><font face="Calibri" size="2" class=""><span style="font-size:11pt" class="">
<div class=""><font color="#1F497D" class=""> </font></div>
<div class=""><font color="#1F497D" class="">We shouldn’t give up vectorizing simply because programmer wrote a FP induction code.(*)</font></div></span></font></div></blockquote><div class=""><br class=""></div><div class="">We shouldn't add code to the compiler just because we can.</div><div class=""><br class=""></div><div class="">I would similarly be against, for example, vectorizing loops with binary coded decimal induction variables, and adding an entire BCD SCEV infrastructure, without some motivating case *somewhere*.</div><div class=""><br class=""></div><div class="">So i suggest y'all start from: "Here are the cases we care about making faster, and why we care about making them faster”.</div></div></div></div></div></blockquote>+1 I think a lot of people would be very interested in non-toy examples that show big performance differences between icc and clang. That would also allow to dig deeper into questions like is it “vectorizer capability, dependence analysis and/or supporting transformations and/or ??? ” to explain the gap.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">In compilers, building infrastructure first, then finding customers works a lot worse than figuring out what customers want, and then building infrastructure for them :)</div><div class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>