[aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Paul Sandoz]

> On May 22, 2020, at 10:40 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 5/22/20 5:12 PM, Paul Sandoz wrote:
> 
>> I am not terribly familiar with the AArch64 code, but I would note
>> the Vector API comes with a bunch of unit tests should exercise the
>> code gen, just not as directly as I presume you would like.
> 
> Yes, you've understood me: direct is what I want. The assembler tests
> are intended to make sure we generate exactly the right instructions,
> rather than having something painfully hard to debug later on. When a
> patch adds a lot of instructions to the assembler, that IMO is the
> right time to test that they generate correctly-encoded
> instructions. But yes, that can go into a follow-up patch, as long as
> it gets done fairly shortly.

Ok.


> 
>> To what extent do you feel we can follow up with additional issues
>> and fix them after the initial integration?
> 
> We can do that. Note that after this patch, aarch64.ad is 21762 lines
> long. I know we don't have any hard-and-fast rule about this, but I'd
> rather it didn't get forgotten.

We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden.

(FWIW I don’t know to what extent some functionality is utilized by the auto vectorizer and whether that impacts its location or not.) 


> Maybe I should do that one myself, but
> I guess I'd rather avoid the problem of version skew between the
> Panama repo and mainline. That'd make merging rather grim.
> 
> Yang, against which repo is this webrev intended to be applied?
> 

I cannot speak for Yang but we have been generating webrevs from the Panama dev repo, branch vector-unstable (unfortunate name I know!) and doing:

  hg diff -r default

Where the default is regularly, but manually, pulled from jdk/jdk.

More specifically:

- code is generally pushed to the vectorIntrinsics branch

- on a manual but regular basis vectorIntrinsics is synced up to jdk/jdk (via the default branch).

- on a manual but regular basis vector-unstable is synced with vectorIntrinsics

- occasionally there are fixes pushed directly to vector-unstable for the purposes of integration (e.g. removal of the perf test or the x64 SVML stubs).

Hth,
Paul.