Re: Proposing more portable vector cod
Thanks for the reply. I was not asking for non-power of 2 LMUL. I was asking about LMUL values not supported by some implementation.
Let’s say that for SEW=128, an implementation supports LMUL=1 but no other values of LMUL. If the software ties to use a widening operation with SEW=64 and LMUL=1, then the EEW for the wide operand will be 128 and the EMUL will be 2. The EEW/EMUL combination (128/2) is not supported on this implementation. However, 128/1 is. If we reduce VL instead of taking an illegal instruction exception, the code will work.
From: Nick Knight <nick.knight@...>
CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.
Thanks for your comments. I apologize, but I don't fully understand your proposal, or the problem it solves. To help explain my confusion, here are two thoughts.
The supported LMUL (and EMUL) values are 2^k (k = -3:3) on all implementations, so software requesting EMUL > 8 is illegal everywhere.
I agree that we could make widening instructions more flexible by having them decrease VL (and LMUL) so that EMUL becomes valid. The fault-first loads adjust VL automatically, so this is not without some precedent. However, In my opinion, it's too much of a burden to do this manually (using vsetvli), and I don't see any portability issues with that.
On Tue, Sep 29, 2020 at 9:32 AM Joseph Rahmeh <Joseph.Rahmeh@...> wrote: