RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics

[John Rose]

On May 20, 2021, at 8:31 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 5/20/21 12:34 AM, Paul Sandoz wrote:
>> I don’t think this should be considered a generally acceptable approach for Vector API operations (most code for operations does not and should not follow this approach), nor is it generally acceptable for other kinds of intrinsic in HotSpot (I believe there are a few special cases under os_cpu). Thus we should dissuade the use of .S source for other intrinsic cases.
> 
> I've got nothing at all against .S files, as long as they are the real
> preferred form. That is to say, they should be the actual source code,
> as written by someone.

Yes, these .S files are a somewhat painful compromise which
we are committed to improve.

Intel is contributing them as a one-time artifact which we are,
in fact, responsible to maintain.  By hand, as the preferred
form of the source.  (Preferred to what??  Well, preferred to
nothing at all.)  The only reason we are doing this we are
inside the incubation process.  We know we will change the
code moving forward.  But for now we want a timely release
of an unfinished work for evaluation by the community.
And that’s pretty much what incubation is for, right?

So I’ll characterize the current sources as just-barely-workable
by hand, just enough to do very light maintenance and vetting,
although totally impractical for meaningful improvement,
such as dealing with issues like 0.5ULP behavior and monotonicity.
These are not the sources you are looking for that future work.

Exiting incubation, any of the following options seem allowable
to me, in the way that the current sources are not allowable:

- using a very slow element-wise loop over JDK math methods
- using well-written assembly code (which does not exist now)
- using well-written C/asm code from some open source project
- bundling a library from appropriate sources with appropriate permissions
- using the Vector API itself to write portable numerics

That last option seems very desirable, and getting the Vector API
into incubation, with well-performing math primitives, is a giant
step forward in that direction.  And we want to go in that general
direction anyway (whether we use special math libraries or not).

> 
>> Does this help alleviate some of your concerns?
> 
> Somewhat, but I wonder if this, as a matter of policy, is an area in
> which the Governing Board should get involved. I don't want to hold up
> progress, of course, but this is potentially a very important issue.

I think this could rise to the GB level if we needed to make a strong
policy change, but as I’ve said above, I think we are in policy here.
(Just barely.)  For any conceivable issue of maintainability, surely the
open review process is enough, without asking the GB to weigh in
on change set reviews.  And I think this is about maintainability.

> I guess I wouldn't mind as long as we had a "This far, and no further"
> policy, with some hope that the library could be replaced by readable
> and maintainable code.

Well in this case, we have two things:

1. Temporary expedient only for incubation, to gain public feedback.
2. Clear call for a plausible alternative, to be answered before incubation exit.

That’s probably enough “case law” to help clarify the relevant policy.

What do you think?

— John