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

[Vladimir Ivanov]

>>> 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 believe you are referring to ubiquitous presence of predicates in AD 
instructions for vector cases. The root cause is that operands have very 
limited influence on matching logic. There's a promising idea to 
introduce predicated operands and factor complex predicates into a set 
of simpler ones placed on operands instead. It should significantly 
reduce the perceived complexity, but the prototyping hasn't been 
finished yet.

[...]

>>> 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.

One more point on naming: though it was me who proposed the name "vec" 
on x86, I don't think it's the best option anymore. Considering it's 
desirable to get rid of VecS/VecD/VecX/... machine ideal registers and 
replace them with a single one, I think using Op_RegV is a better 
alternative to Op_Vec. Hence, regV/rRegV/vReg look better (depending on 
conventions adopted in particular AD file).

Best regards,
Vladimir Ivanov