[aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support
vladimir.x.ivanov at oracle.com
Fri Aug 28 09:56:10 UTC 2020
>>> 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
>>> 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,
> 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).
More information about the aarch64-port-dev