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

[Andrew Haley]

On 5/17/21 6:51 PM, Paul Sandoz wrote:
> I’ll let Sandhya talk more about the provenance and numerical accuracy. I think we can add more comments/details in that respect.
> 
> IMO this is a reasonable compromise, at least for incubation with follow on investigation to determine if we can leverage possible enhancements to Panama FFM (see JEP 414 section on SVML). We would like encourage experimentation of numerical data-parallel algorithms. The performance gains using SVML are compelling in that regard.

I understand the argument from utility here, but it's a very substantial
precedent to take. In the licence we use for OpenJDK, the "source code" for
a work means the preferred form of the work for making modifications to it.
This is not the preferred form. These assembly-code files are not much more
use than binary blobs would be. They are a black box.

(I'm aware that we've had a few of these from Intel before, but ISTM that
this is a much bigger deal.)

I understand that permission to include these files was probably granted as
a result of negotiations with Intel. And it's great to have this code in
OpenJDK.

However, I am sure that no-one on this project looks forward to a future
in which part of our "source code" consists of what are in effect unfixable
binary blobs. We should at least have the conversation about whether this
is the way OpenJDK should be going.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671