<div dir="ltr"><div>Hi Sander,</div><div><br></div><div>Awesome work from everyone involved. Thank you very much for your efforts!</div><div><br></div><div>I know some people wanted it to go a lot faster than it did, but now we have an infrastructure that has reached consensus across different companies and industries. </div><div><br></div><div>We're finally discussing high level vectorisation strategies without having to worry about the mechanics of scalable vector representation. This is a big long term win.</div><div dir="ltr"><br></div><div dir="ltr">On Wed, 11 Nov 2020 at 22:06, Sander De Smalen <<a href="mailto:Sander.DeSmalen@arm.com">Sander.DeSmalen@arm.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We (Arm) prefer starting out with adding support for 1 in upstream LLVM, because it is the easiest to support and gives a lot of ‘bang for buck’ that will help us incrementally add more scalable auto-vec capabilities to the vectorizer. A proof of concept of what this style of vectorization requires was shared on Phabricator recently: <a href="https://reviews.llvm.org/D90343" rel="noreferrer" target="_blank">https://reviews.llvm.org/D90343</a>.<br>
<br>
Barcelona Supercomputer Centre shared a proof of concept for style 2 that uses the Vector Predication Intrinsics proposed by Simon Moll (VP: <a href="https://reviews.llvm.org/D57504" rel="noreferrer" target="_blank">https://reviews.llvm.org/D57504</a>, link to the POC: <a href="https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi" rel="noreferrer" target="_blank">https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi</a>). In the past Arm has shared an alternative implementation of 2 which predates the Vector Predication intrinsics (<a href="https://reviews.llvm.org/D87056" rel="noreferrer" target="_blank">https://reviews.llvm.org/D87056</a>).<br></blockquote><div><br></div><div>I think both are equally good. The third one seems a bit too restrictive to me (but I'm probably missing something).</div><div><br></div><div>I have previously recommended (1) for the sake of simplicity in implementation (one step at a time), but I don't see anything wrong in us trying both, even at the same time. Or even a merged way where you first vectorise, then predicate, then fuse the tail.</div><div><br></div><div>We have enough interested parties that we can try out multiple solutions and pick the best ones, or all of them. And as you say, they'll all use the same plumbing, so it's more sharing than competing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hopefully in a couple of months we’ll be able to slowly enable more scalable vectorization and work towards building LNT with scalable vectors enabled. When that becomes sufficiently stable, we can consider gearing up a BuildBot to help guard any new changes we make for scalable vectors.<br></blockquote><div><br></div><div>This would be great, even before it's enabled by default.<br></div><div><br></div><div>cheers,</div><div>--renato</div></div></div>