RFR: jextract generates BigDecimal for "long double" but binder fails to handle it

[Sundararajan Athijegannathan]

Looks good!

* The following files miss copyright

test/jdk/com/sun/tools/jextract/complex/libcomplex_aux.h
test/jdk/com/sun/tools/jextract/complex/libcomplex_aux.c
test/jdk/java/foreign/libLongDouble.c

* Unused import of BigDecimal in
    src/java.base/share/classes/java/foreign/NativeTypes.java
    src/java.base/share/classes/java/foreign/memory/LayoutType.java
    src/java.base/share/classes/jdk/internal/foreign/Util.java

I tested the changeset on Mac and all tests fine (with product mode binary)

-Sundar

On 05/11/18, 3:57 PM, Maurizio Cimadamore wrote:
> Hi,
> this patch adds support for X87 values in the binder
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8213029/
>
> The Hotspot changes are straightforward; there's a new X87 shuffle 
> recipe category which needs to be taken into account (its size is 128 
> bits). Changes are needed on the binder side too as the X87 arguments 
> have to be properly classified.
>
> More specifically, the ABI is very subtle when it comes to 'complex' 
> values; they are generally passed in stack slots (if they are in 
> argument position) but they are passed in registers (X87 st0 for 'long 
> double' or both 'st0' and 'st1' for 'long double complex') for return 
> values. To achieve this, we need to teach the binder about the special 
> LongDoubleComplex struct, so that the right classification occurs (see 
> changes to CallingSequenceBuilderImpl).
>
> Another issue is how to handle X87 values in Java - I started out 
> trying to map these values to BigDecimal, but after getting it to work 
> I realized that there were too many unanswered questions: one 
> performance side, to decode an X87 value into a BigDecimal you have to 
> create lots of intermediate BigIntegers/BigDecimal; on the 
> expressiveness side, BigDecimal is lacking support for NaN/Infinity, 
> making it an improper fit.
>
> I then decided to 'erase' X87 values down to 'double' (using a JNI 
> helper function to do the conversion, which should be efficient as it 
> can take advantage of platform specific instructions such as flstp etc.).
>
> I tested it with fast-debug to make sure there were no weird hotspot 
> failures, but please give it a spin to make sure it all works.
>
> I also updates existing complex tests to add more cases and upcall 
> support.
>
> Cheers
>
> Maurizio
>
>
>