Re: Issue categorization - #460

David Horner

On 2020-06-29 10:36 a.m., Krste Asanovic wrote:
Can you focus on what would not be possible if we ratified current proposal.

Remember EDIV is not in 1.0

It is a planned extension,  that even if not implemented as currently proposed it will likely consume at least 2 bits in vtype.

Do you envision a possibility that it will consume no vtype bits?

The reality is that the 32bit encoding is highly dependent upon vtype to reduce opcode space by providing common fields dynamically.

Of course, the ideal candidates for vtype inclusion are modifiers that will remain constant over many  vector instructions.

vlmul and vsew fit the requirements.

We don't know yet if vma and vta are going to be sufficiently variable and sufficiently constant over op sequences to be useful in vtype.

But there they are using up 2 bits for an anticipated performance (and in my mind "software precision/accuracy") benefit.

I agree that their inclusion in V1.0 was necessary for their inclusion into the full ecosystem.

However, they are an example of how quickly bits can be consumed by anticipated vs proven need.

Post V1.0 we will be more cautious in inclusion into vtype.

Fortunately, the custom space will allow explicit testing of the relative merit of various extensions vying for inclusion in vsetvli.

However, the fewer bits available in the base vsetvli the more likely we will have to reject equally useful opcode extensions from concurrent use and the most efficient code sequences.

and Vlmul=100 is reserved

I expect it will be useful for encoding parameters that do not require lmul, e.g. one related to mask ops.

But even trying to think of an potential use for ops that don't use lmul (or always a default lmul value of say 8) is challenging.

So, one might be temped to think that it would then be useful as an extension flag.

However, the very ubiquitous nature of lmul would mean that the extension would also encode lmul using 3 bits.

Thus the benefit is lost; For an alternate encoding that provides n more bit (such as #460 that provides 6) the net increase is only n-2 bits.

Not a winning solution in the anticipated "lmul is required" encoding space.


On Jun 29, 2020, at 7:28 AM, David Horner <ds2horner@...> wrote:

minor typos; substantial correction:

Join to automatically receive all group messages.