[llvm-dev] [RFC] Vector Predication
Simon Moll via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 5 05:18:43 PST 2019
On 2/5/19 2:00 PM, Bruce Hoult wrote:
> 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
>> state of RVV in that regard.
>> This seems to imply that enforcing MVL changes only per function level
>> is now moot (as in
> 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.
Ok. I am just poking around a little to see whether something like
would be compatible with your solution for MVL configuration in RVV
Researcher / PhD Student
Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31
Tel. +49 (0)681 302-57521 : moll at cs.uni-saarland.de
Fax. +49 (0)681 302-3065 : http://compilers.cs.uni-saarland.de/people/moll
More information about the llvm-dev