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

[Maurizio Cimadamore]

On 05/11/2018 15:40, Jorn Vernee wrote:
> 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).

I think there's a general feeling that X87 types are on the verge of 
being "deprecated" by both Intel and AMD; System V for instance uses SSE 
registers for quad precision doubles (__float128), so I guess we'd be 
interesting in hearing of cases where X87 long double is still actively 
being used. If this turns out to be a common enough case we can revisit 
and add proper functionality but I'd say that for now what we have 
should be a good enough compromise between functionalities and performances.

Maurizio

>
> 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
>>>
>>>
>>>