<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><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><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><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><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><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">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">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">EPI
          Project</a>. We earlier shared a demo of our prototype
        implementation  (<a href="https://repo.hca.bsc.es/epic/z/9eYRIF" target="_blank">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">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">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">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">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">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">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">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">http://www.bsc.es/disclaimer</a>
<br>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>