[PATCH] D57504: RFC: EVL Prototype & Roadmap for vector predication in LLVM

[Simon Moll via Phabricator via llvm-commits]

simoll planned changes to this revision.
simoll added a comment.

Planned (Accepted)
------------------

- EVL -> VP (for vector predication). That is `llvm.vp.fsub` and `vp_fsub` (https://reviews.llvm.org/D57504#inline-509343).
- The unit of the vlen parameter is the vector element type (to clarify: the interpretation of vlen is unaffacted by the `vscale` of scalable vector types) (https://reviews.llvm.org/D57504#1387621)



Open (Required)
---------------

- Required only by RVV/SV: `%avl = llvm.vp.setvl(<scalable vscale x elty>, %avl)` (https://lists.llvm.org/pipermail/llvm-dev/2019-February/129971.html).
  - The signature for this is unclear, eg VMul could be encoded as a constant (immarg attribute - https://lists.llvm.org/pipermail/llvm-dev/2019-February/129983.html).
  - Can the `vlen` parameter of function be used in the function's body as is without passing it through the intrinsic first? -> important for Whole-Function Vectorization.

- TTI Queries:
  - What is the native scalable sub-vector size (128bit on SVE, 64bit on SX-Aurora, ..)?
  - What is the native vlen granularity for this target and element size (eg 64bit grain for SX-Aurora, element-wise for RVV/SV)?

Open (Future Work)
------------------

- Untying the mask scale from the data scale. This would allows masking at a sub-vector level (eg each mask bit refers to a <3 x float> sub-vector of <scalable 3 x float>) (https://lists.llvm.org/pipermail/llvm-dev/2019-February/129845.html).
- Decoupling the pointer vector size from the transferred data size (eg `<16 x float> llvm.vp.gather.v16f32(<8 x float*>, %M, %L)` loads pairs of floats) - (https://lists.llvm.org/pipermail/llvm-dev/2019-February/129942.html)



Food for thought
----------------

- Use of higher-order functions to encode reductions, eg:

  %reduced = call float @llvm.vp.reduce.nxv2f32(@llvm.vp.fadd.f32, %Mask, %Len, float 0.0, <scalable 2x f32> %DataVector)

This means less intrinsics, the passed-in function could also be user-defined.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57504/new/

https://reviews.llvm.org/D57504