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

[Jorn Vernee]

Changes look good!

I'm still not sure that compromising on functionality rather than 
performance (using `double` vs. `BigDecimal`) is the right move tbh, but 
if it's temporary any ways then I feel like it's not worth discussing 
right now. That's just the reality of prototyping, that some things 
don't have full functionality (yet).

Though I'm always glad to exchange thoughts of course!

Cheers,
Jorn

Maurizio Cimadamore schreef op 2018-11-05 15:38:
> Updated webrev:
> 
> http://cr.openjdk.java.net/~mcimadamore/panama/8213029_v3
> 
> Thanks for the comments
> 
> Maurizio
> 
> On 05/11/2018 10:27, 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
>> 
>> 
>>