[llvm-dev] [RFC] Vector Predication

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 5 05:00:31 PST 2019


On Tue, Feb 5, 2019 at 4:28 AM Simon Moll <moll at cs.uni-saarland.de>
wrote:> Thank you for the detailed explanation! I wasn't aware of the
current
> state of RVV in that regard.
>
> This seems to imply that enforcing MVL changes only per function level
> is now moot (as in
> https://lists.llvm.org/pipermail/llvm-dev/2018-April/122517.html).

As Robin said even at that time:

==============
# Runtime-varying vector length in the IR

This is achieved by simply declaring "by fiat" that the vector length is
determined on function entry and remain constant for the rest of the
function execution. Other functions and other calls to the same function
may observe a different vector length, but within one call to a given
function, the vector length is fixed. That is not precisely how the
hardware works, but it is a contract the backend can uphold easily
==============

i.e. that's not a restriction imposed by the hardware, but writing the
compiler that way *might* make the compiler simpler, at the cost of
missing out on some of the flexibility in the hardware.

That's still exactly as applicable or inapplicable now as then.

Robin also said then:

==============
For scenarios like two entirely separate vectorized loops within one
function, it might be useful to drastically change the vector unit
configuration in the middle of a function.
==============

So, no real change or disagreement, it's just a question of how to
expediently shoehorn *something* into LLVM, on which I definitely
defer to Robin and Alex.


More information about the llvm-dev mailing list