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

[Andrew Dinn]

On 28/08/2020 06:56, Ningsheng Jian wrote:
> On 8/27/20 8:54 PM, Vladimir Ivanov wrote:
>> I definitely don't want to hinder/block the impressive work Ningsheng
>> and others at Arm are doing for SVE support.
>>
>> Frankly speaking, my main concern is that the implementation can stay
>> that way forever ;-) That's why I'm trying to get enough ground covered
>> in the discussion and some agreements/commitments to be made before it
>> is integrated.

Sure, I agree that we should use this implementation as a stepping stone
to a set of unified AArch64 vector rules that handle operations for
vectors of all size. Having looked at the latest x86 vector code I get
the impression that there is a much greater problem unifying the
plethora of different cases within the x86_64 family than there will be
unifying x86_64 and AArch64 in this regard. Your solution of using the
vec (and legVec) register class(es) has tamed the proliferation of match
rules yet it still leaves a great deal of complexity in the logic that
controls the handling of those matches.

I think it will be much easier to subsume the AArch64 Neon and SVE cases
under one common vec type and the resulting case handling will be much
less complex. Of course, the rationale for doing so is far less pressing
than with x86 since the multiplication of match rules is not so large
(particularly as there is no cross-combination with memory operands).
Yet, it still seems worth doing.

>> Leaving RA part aside, I have one suggestion which should help in the
>> future: let's try to consistently follow full-width vector abstraction.
>> In AD file, vecA operand is way too similar to vecX et al which makes a
>> wrong impression it's yet another vector flavor. So, choosing a better
>> name will help when representation changes. For example, x86 moved away
>> from vecX/... operands to a single generic one (called "vec") and you
>> can take a loot at x86.ad to see the result.
> 
> Thanks for the suggestion. In current implementation vecA does not
> include vecD/vecX for NEON - so actually it's regarded as another vector
> flavor. We try to keep the SVE implementation separated from original
> NEON code (and a new ad file is also introduced), to make the code
> better maintainable and reviewable. What do you think about this naming,
> Andrew?
If the goal is that eventually a vec register class will parametrize the
relevant rules for VecD, VecX and VecA operations then I don't see any
harm in re-labelling the vecA class to simply be called vec. The
intention to use this to handle all cases can be signalled by
documenting this register class to explain that it is currently only
used to specify VecA rules but will eventually be used as a generic
class, parameterizing rules that subsume all applicable VecD, VecX and
VecA cases. When that happens we can quite naturally fold the
aarch64_sve rules back into aarch64.ad with common and/or special case
handling merging under a single rule.

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