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

[Maurizio Cimadamore]

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