Vector API reproducibility bug (?)

[Paul Sandoz]

> On Aug 19, 2022, at 12:16 AM, Xiaohong Gong <Xiaohong.Gong at arm.com> wrote:
> 
> Thanks for the explanation @Paul Sandoz!
> 
>>>> (It may be possible to fix this difference between the interpreter and
>>>> C2 for the vector operations, but it would some work to do so.)
>>>> 
>>> 
>>> OK, do you have a plan to fix this difference?
>>> 
>> 
>> Not currently. We would need to appeal to native methods in the vector operation fallback code.
> 
> So what should be the implementation of native methods in your mind? We may also need to consider other architectures, not just x86 (and aarch64) that I don't know what the impact would be. 
> 
>> 
>>> Thinking about such kind of optimization for AArch64, I noticed that there were some questions about the code quality and maintainability of SVML assembly [1]. As John also mentioned about other possible alternatives [2], my colleague pointed me a good project, SLEEF [3], which looks promising in terms of portability, quality and performance [4]. (I don't know much about license compatibility with OpenJDK.)
>> 
>> That might be an option for AArch64, although like you I am unsure about license. I am confident of the code quality of the SVML assembly given it's origin.
>> 
>> Ideally (and I think this might have been part of the discussion) we would wire up the stubs from a library on the library path, thereby we don’t have to distribute the source with the platform (leaving open the option of how to distribute the optionally dependent library).
> 
> Yeah, I agree with you that calling the stubs from a library instead of distributing the source for each platform is a good solution. Since SVML doesn’t support other architectures, a common library that supports all architectures should be a better solution. And it will be much better and easier to maintain if a public common library can be used for ALL platforms. So I think SLEEF can be an option, even for x86. Or do we have any other candidates? 
> 

SVML code is already established for x86 implementations. I don’t know of other candidates. SLEEF could be worth exploring for other platforms.


> BTW, to fix the results different issue from intrinsic and interpreter, should we use the exact same native implementation like what it calls by intrinsics in the java fallback code?
> 

Yes.

So the following might change:

case VECTOR_OP_ACOS: return (v0, m) ->
        v0.uOp(m, (i, a) -> (float) Math.acos(a));

to something like this:

case VECTOR_OP_ACOS: return (v0, m) -> {
         if (VectorIntrinsics.accuracyOrMonotonicityDiffersFromScalar(VECTOR_OP_ACOS)) { // native call
             float[] vec = vec();
             float[] res = new float[length()];
             VectorIntrinsics.nativeUnaryOperation(VECTOR_OP_ACOS , vec, res); // native call
         } else {
             return v0.uOp(m, (i, a) -> (float) Math.acos(a));
         }
       };

Paul.