Page MenuHomePhabricator

[RISCV] Add a proof-of-concept for supporting fixed-length vectors in RVV
Needs ReviewPublic

Authored by frasercrmck on Nov 17 2020, 8:55 AM.

Details

Summary

Hidden behind a compilation option -riscv-fixed-len-rvv, the RISC-V
backend may now compile simple functions for non-scalable v2i32 and
v4i32 vector types.

The approach is VLEN-agnostic but assumes VLEN>=64, much like the
scalable RVV support. This allows the compiler to support any 64-byte
vector type with a consistent ABI:

v2i8:   e8,  m1, AVL=2
v2i32:  e32, m1, AVL=2
v4i32:  e32, m2, AVL=4
v16i16: e16, m4, AVL=16
v8i64:  e64, m8, AVL=8
v16i32: e32, m8, AVL=16

There are tradeoffs to this design. Requiring an LMUL=8 for v16i32 even when VLEN>=512 could fit it in LMUL=1 is an example.

Other designs are available, such as by supporting non-scalable vectors by compiling for a specific VLEN, and/or by using VLMAX equal to the vector length. It's not clear to me how well LLVM would cope with this design, though.

Diff Detail

Unit TestsFailed

TimeTest
50 msx64 windows > Clangd Unit Tests._/ClangdTests_exe::ProviderTest.FromAncestorRelativeYAMLFiles
Note: Google Test filter = ProviderTest.FromAncestorRelativeYAMLFiles [==========] Running 1 test from 1 test case.
80 msx64 windows > LLVM.CodeGen/XCore::threads.ll
Script: -- : 'RUN: at line 1'; c:\ws\w1\llvm-project\premerge-checks\build\bin\llc.exe -march=xcore < C:\ws\w1\llvm-project\premerge-checks\llvm\test\CodeGen\XCore\threads.ll | c:\ws\w1\llvm-project\premerge-checks\build\bin\filecheck.exe C:\ws\w1\llvm-project\premerge-checks\llvm\test\CodeGen\XCore\threads.ll

Event Timeline

frasercrmck created this revision.Nov 17 2020, 8:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 17 2020, 8:55 AM
frasercrmck requested review of this revision.Nov 17 2020, 8:55 AM

This is along the lines of the patch I was working on. I used a new .td file of patterns and started with 64 bit vector types based on the minimum VLEN from Evandro and Roger's RFC.

This is along the lines of the patch I was working on. I used a new .td file of patterns and started with 64 bit vector types based on the minimum VLEN from Evandro and Roger's RFC.

Makes sense; thanks. Evandro indicated to me that the minimum may become 128 so I jumped on that as it fits OpenCL vectors nicely, but if it's 64 it doesn't change a whole lot.

How concerned are people about this approach? Is it future-proof enough? How big is VLEN going likely to get? Is this too inefficient in terms of register usage?

arcbbb added a subscriber: arcbbb.Nov 25 2020, 1:29 AM
khchen added a subscriber: khchen.Nov 25 2020, 5:25 PM
frasercrmck edited the summary of this revision. (Show Details)
  • Rebase on top of main branch
  • Switch terminology from non-scalable to fixed-length
  • Assume VLEN>=64 rather than VLEN>=128
  • Reduce size of diff against main branch
frasercrmck retitled this revision from [RISCV] Add a proof-of-concept for supporting non-scalable vectors in RVV to [RISCV] Add a proof-of-concept for supporting fixed-length vectors in RVV.Dec 7 2020, 3:13 AM
frasercrmck edited the summary of this revision. (Show Details)
frasercrmck edited the summary of this revision. (Show Details)
wuiw added a subscriber: wuiw.Dec 7 2020, 3:31 AM

Does anyone have any comments about this approach or how to take it further?