> On May 22, 2020, at 10:40 AM, Andrew Haley <a...@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.
