<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Renato,</p>
<p>Thanks a lot for your comments!</p>
<p>(more inline.)</p>
<p><br>
</p>
<p>Thanks and Regards,</p>
<p>Vineet</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2020-11-02 5:43 p.m., Renato Golin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPH-gffU4vNEEe+LiVey1k8oKuVUSscHYcghhWgZEkXaDynwCg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Vineet,
<div><br>
</div>
<div>Thanks for sharing! I haven't looked at the code yet, just
read the README file you have and it has already answered a
lot of questions that I initially had. Some general
comments...</div>
<div><br>
</div>
<div>I'm very happy to see that Simon's predication changes were
useful to your work. It's a nice validation of their work and
hopefully will help SVE, too.</div>
</div>
</blockquote>
Simon's vector predication ideas fit really nicely with our approach
to predicated vectorization, specially the support for EVL
parameter. We look forward to more discussions around it.<br>
<blockquote type="cite"
cite="mid:CAPH-gffU4vNEEe+LiVey1k8oKuVUSscHYcghhWgZEkXaDynwCg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Your main approach to strip-mine + fuse tail loop is what I
was going to propose for now. It matches well with the
bite-sized approach VPlan has and could build on existing
vector formats. For example, you always try to strip-mine (for
scalable and non-scalable) and then only for scalable, you try
to fuse the scalar loops, which would improve the solution and
give RVV/SVVE an edge over the other extensions on the same
hardware.</div>
</div>
</blockquote>
While our implemented approach with tail folding and predication is
guided by the research interests of the EPI project, I agree that
for a more general implementation your proposed approach for now
makes more sense before moving on to better predication support and
exploring other approaches.<br>
<blockquote type="cite"
cite="mid:CAPH-gffU4vNEEe+LiVey1k8oKuVUSscHYcghhWgZEkXaDynwCg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>There were also in the past proposals to vectorise the tail
loop, which could be a similar step. For example, in case the
main vector body is 8-way or 16-way, the tail loop would be
7-way or 15-way, which is horribly inefficient. The idea was
to further vectorise the 7-way as 4+2+1 ways, same for 15. If
those loops are then unrolled, you end up with a nice decaling
down pattern. On scalable vectors, this becomes a noop.</div>
<div><br>
</div>
<div>There is a separate thread for vectorisation cost model [1]
which talks about some of the challenges there, I think we
need to include scalable vectors in consideration when
thinking about it.</div>
</div>
</blockquote>
Agreed. It would be very useful to think about a scalable vectors
aware cost-model right from the beginning now that there is effort
already underway to integrate it into VPlan. There was also a
discussion around it in the latest SVE/SVE2 sync-up meeting and I
think almost everyone was in agreement.<br>
<blockquote type="cite"
cite="mid:CAPH-gffU4vNEEe+LiVey1k8oKuVUSscHYcghhWgZEkXaDynwCg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>The NEON vs RISCV register shadowing is interesting. It is
true we mostly ignored 64-bit vectors in the vectoriser, but
LLVM can still generate them with the (SLP) region vectoriser.
IIRC, support for that kind of aliasing is not trivial (and
why GCC's description of NEON registers sucked for so long),
but the motivation of register pressure inside hot loops is
indeed important. I'm adding Arai Masaki in CC as this is
something he was working on.</div>
</div>
</blockquote>
<p>Thanks for adding Arai! I will be happy to pick their brain on
the the topic.<br>
</p>
<p>One specific place where we have to deal with it is when
computing a feasible max VF. I am currently experimenting with an
approach to have user specify (via a command line flag) a vector
register width multiplier - a factor by which the operating vector
register width would be the multiple of the minimum vector
register width and then based on that, estimate the highest VF
that won't spill registers (relies on TTI for information about
the number of registers in relation to register width). This is
definitely not a generic solution and probably not elegant either
but personally it serves as a starting point to think about the
broader issue.<br>
</p>
<blockquote type="cite"
cite="mid:CAPH-gffU4vNEEe+LiVey1k8oKuVUSscHYcghhWgZEkXaDynwCg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Otherwise, I think working with the current folks on VPlan
and scalable extensions will be a good way to upstreaming all
the ideas you guys had in your work.</div>
</div>
</blockquote>
That's the plan!<br>
<blockquote type="cite"
cite="mid:CAPH-gffU4vNEEe+LiVey1k8oKuVUSscHYcghhWgZEkXaDynwCg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Thanks!</div>
<div>--renato</div>
<div><br>
</div>
<div>[1] <a
href="http://lists.llvm.org/pipermail/llvm-dev/2020-October/146236.html"
moz-do-not-send="true">http://lists.llvm.org/pipermail/llvm-dev/2020-October/146236.html</a></div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 2 Nov 2020 at 15:52,
Vineet Kumar via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi all, </p>
<div>
<p>At the Barcelona Supercomputing Center, we have been
working on an end-to-end vectorizer using scalable
vectors for RISC-V Vector extension in context of the <a
href="https://www.european-processor-initiative.eu/accelerator/"
target="_blank" moz-do-not-send="true">EPI Project</a>.
We earlier shared a demo of our prototype
implementation (<a
href="https://repo.hca.bsc.es/epic/z/9eYRIF"
target="_blank" moz-do-not-send="true">https://repo.hca.bsc.es/epic/z/9eYRIF</a>,
see below) with the folks involved with LLVM SVE/SVE2
development. Since there was an interest in looking at
the source code during the discussions in the subsequent
LLVM SVE/SVE2 sync-up meetings, we are also publishing a
public copy of our repository. <br>
</p>
<p>It is available at <a
href="https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi"
target="_blank" moz-do-not-send="true">https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi</a>
and will sync with our ongoing development on a weekly
basis. Note that this is very much a work in progress
and the code in this repository is only for reference
purpose. Please see the <a
href="https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi/-/blob/EPI/README.md"
target="_blank" moz-do-not-send="true">README</a> file
in the repo for details on our approach, design
decisions, and limitations.</p>
<p>We welcome any questions and feedback. <br>
</p>
</div>
<div><br>
<pre>Thanks and Regards,
Vineet Kumar - <a href="mailto:vineet.kumar@bsc.es" target="_blank" moz-do-not-send="true">vineet.kumar@bsc.es</a>
Barcelona Supercomputing Center - Centro Nacional de Supercomputación
</pre>
<div>On 2020-07-29 3:10 a.m., Vineet Kumar wrote:<br>
</div>
<blockquote type="cite">
<pre>Hi all,
Following up on the discussion in the last meeting about auto-
vectorization for RISC-V Vector extension (scalable vectors) at the
Barcelona Supercomputing Center, here are some additional details.
We have a working prototype for end-to-end compilation targeting the
RISC-V Vector extension. The auto-vectorizer supports two strategies to
generate LLVM IR using scalable vectors:
1) Generate a vector loop using VF (vscale x k) = whole vector register
width, followed by a scalar tail loop.
2) Generate only a vector loop with active vector length controlled by
the RISC-V `vsetvli` instruction and using Vector Predicated intrinsics
(<a href="https://reviews.llvm.org/D57504" target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D57504</a>). (Of course, intrinsics come with
their own limitations but we feel it serves as a good proof of concept
for our use case.) We also extend the VPlan to generate VPInstructions
that are expanded using predicated intrinsics.
We also considered a third hybrid approach of having a vector loop with
VF = whole register width, followed by a vector tail loop using
predicated intrinsics. For now though, based on project requirements,
we favoured the second approach.
We have also taken care to not break any fixed-vector implementation.
All the scalable vector IR gen is guarded by conditions set by TTI.
For shuffles, the most used case is broadcast which is supported by the
current semantics of `shufflevector` instruction. For other cases like
reverse, concat, etc., we have defined our own intrinsics.
Current limitaitons:
The cost model for scalable vectors doesn't do much other than always
decideing to vectorize with VF based on TargetWidestType/SmallestType.
We also do not support interleaving yet.
Demo:
The current implementation is very much in alpha and eventually, once
it's more polished and thoroughly verified, we will put out patches on
Phabricator. Till then, we have set up a Compiler Explorer server
against our development branch to showcase the generated code.
You can see and experiment with the generated LLVM IR and VPlan for a
set of examples, with predicated vector loop (`-mprefer-predicate-over-
epilog`) at <a href="https://repo.hca.bsc.es/epic/z/JB4ZoJ" target="_blank" moz-do-not-send="true">https://repo.hca.bsc.es/epic/z/JB4ZoJ</a>
and with a scalar epilog (`-mno-prefer-predicate-over-epilog`) at
<a href="https://repo.hca.bsc.es/epic/z/0WoDGt" target="_blank" moz-do-not-send="true">https://repo.hca.bsc.es/epic/z/0WoDGt</a>.
Note that you can remove the `-emit-llvm` option to see the generated
RISC-V assembly.
We welcome any questions and feedback.
Thanks and Regards,
Vineet Kumar - <a href="mailto:vineet.kumar@bsc.es" target="_blank" moz-do-not-send="true">vineet.kumar@bsc.es</a>
Barcelona Supercomputing Center - Centro Nacional de Supercomputación
</pre>
</blockquote>
</div>
<br>
<br>
WARNING / LEGAL TEXT: This message is intended only for the
use of the
individual or entity to which it is addressed and may
contain
information which is privileged, confidential, proprietary,
or exempt
from disclosure under applicable law. If you are not the
intended
recipient or the person responsible for delivering the
message to the
intended recipient, you are strictly prohibited from
disclosing,
distributing, copying, or in any way using this message. If
you have
received this communication in error, please notify the
sender and
destroy and delete any copies you may have received.
<br>
<br>
<a href="http://www.bsc.es/disclaimer" target="_blank"
moz-do-not-send="true">http://www.bsc.es/disclaimer</a>
<br>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
<br>
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
<br><br>
<a href="http://www.bsc.es/disclaimer">http://www.bsc.es/disclaimer</a>
<br>
</body>
</html>