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

[Jorn Vernee]

Never mind the comment about `LongDoubleComplex.java`, I was 
accidentally looking at `DoubleComplex.java`... oops

Jorn

Jorn Vernee schreef op 2018-11-05 12:47:
> Hi,
> 
> I can't run the tests on this, but I thought I'd review any ways since
> I've spent a lot of time with the same code recently.
> 
> LongDoubleComplex.java:
> 
>     Not sure this diff should be in here, the rhs is what I already
> have locally.
> 
> Util.java:
> 
>     Somewhat confusing to do the get and set operations in one method,
> but that's up to you :)
> 
> - I think you've forgotten the diff for
> jdk/internal/foreign/abi/sysv/x64/StorageNames.java ?
> 
> - libcomplex_aux.c, libcomplex_aux.h, and libLongDouble.c are missing
> copyright headers.
> 
> Rest looks good to me.
> 
> On a general note: Did you consider rolling your own
> `Struct<LongDouble>` type as a carrier?
> 
> Cheers,
> Jorn
> 
> Maurizio Cimadamore schreef op 2018-11-05 11:27:
>> 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