[aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

[Andrew Dinn]

Hi Vladimir,

On 25/08/2020 14:18, Vladimir Ivanov wrote:
> I elaborated on some of the points in the thread with Ningsheng.
> 
> I put my responses in-line, but will try to avoid repeating myself too
> much.

Thanks for the response and also clarification in replies to Ningsheng.

So, if I can summarize (please correct me if I misunderstand):

  You are as concerned about existing complexity in vector handling as
much as complexity added by this patch, whether the latter is to AArch64
code or shared code.

  The goal you would like to achieve is a single set of rules for a
single kind of vector register whose size is parameterized, the
appropriate value being derived from each specific vector operation.

  Your main concern about this patch is that it adds yet another
additional vector kind to the current 'wrong' multi-kind vector model
and, what is worse, one with a different behaviour, taking us further
from your desired goal.

  Your other concern is that this design does not allow for the AArch64
ISA predication or, indeed, for what you treat uniformly as the
'implicit' predication imposed on a 'logical' max vector size (2048
bits) by the specific AVX/SVE/NEON hardware vector size.

> But you should definitely prefer 1-slot design for vector registers then
> ;-)

Indeed I do :-]

So, let me respond to the above summary points, assuming I have them
down right.

I agree that your end goal is highly desirable. However, we are not
there yet and since your attempts to do so have not succeeded so far I
don't think that means we are compelled to drop the current patch. As
you say this could (and, if it is adopted, should) be regarded as a
useful stop-gap until we come up with a unified, parameterized vector
implementation that makes it redundant.

That said, I'm not pushing hard to keep the patch if the consequence is
generating significant work later to undo it. The number of users who
might benefit from using SVE vectors from Java now or in the near future
does not look like it is going to be very large (if you are not making a
lot of use of SVE registers then that is a lot of wasted silicon and I
suspect it's going to be the rare case that someone codes an app in Java
that needs to make continuous use of SVE -- mind you, by the same token
I guess that also applies for AVX on Intel).

I'm not sure pushing this now will add a lot more work later. It seems
to me that this code is actually moving in the right direction for the
sort of solution you want. The AArch64 VecA register /is/
size-parameterized, albeit by a size fixed at startup rather than per
operation. So, that's one reason why I don't know if this implies a lot
more rework to move towards your desired goal. Surely, if we do arrive
at a unifying vector model that can replace the existing multi-kind
vectors then it ought to be able to subsume this code - unless of course
it replaces it wholesale.

Are you concerned that adding this patch will result in more cases to
pick through and correct?

Are you worried that we might have to withdraw some of the support this
patch enables to arrive at the final goal?

Also, Ningsheng and his colleagues have laid some foundations for
implementing predicated operations with this patch and have that work in
the pipeline. Once again this is moving towards the desired goal even if
it might end up doign so in a slightly sideways fashion. Perhaps we
could continue this stop-gap experiment as an experimental option in
order to learn from the experience?

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill