Request for reviews (S): 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag

[Vladimir Kozlov]

Thanks, Tom

Vladimir

Tom Rodriguez wrote:
> s/Do floats are conerted/Are floats converted/
> 
> Looks good.
> 
> tom
> 
> On Feb 19, 2010, at 9:40 AM, Vladimir Kozlov wrote:
> 
>> I updated webrev:
>>
>> http://cr.openjdk.java.net/~kvn/6910664/webrev.03
>>
>> Thanks,
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> I was wrong about C1, it already handles this correctly.  It uses float_in_dbl for fpu registers and normal for xmm.
>>> tom
>>> On Feb 19, 2010, at 8:46 AM, Vladimir Kozlov wrote:
>>>> Thank you, Tom
>>>>
>>>> Yes, you are right, I did not thought that I can use Location::normal.
>>>> Then the comment in the .ad files is wrong.
>>>>
>>>> I can fix C1 also if you point me the place.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> Tom Rodriguez wrote:
>>>>> I'm not sure that's the right fix.  The whole point of float_in_dbl is to deal with x86 FPU registers so converting it into some platform dependent thing based on UseSSE doesn't seem right.  I think Matcher::float_in_double should be false if UseSSE >= 1 in x86_32.ad and should always be false in x86_64.ad.  In that case it will use Location::normal instead which will do:
>>>>>     // Just copy all other bits straight through
>>>>>     union { intptr_t p; jint ji;} value;
>>>>>     value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF);
>>>>>     value.ji = *(jint*)value_addr;
>>>>>     return new StackValue(value.p);
>>>>> which is equivalent to your new create_float_stack_value logic.
>>>>> How did we go for so long with this being broken?  It's totally wrong on 64 bit.  C1 has the same problem too.
>>>>> tom
>>>>> On Feb 18, 2010, at 7:08 PM, Vladimir Kozlov wrote:
>>>>>> http://cr.openjdk.java.net/~kvn/6910664/webrev.02
>>>>>>
>>>>>> Fixed 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag
>>>>>>
>>>>>> Problem:
>>>>>> The test has several java float locals and use XMM registers in debug info.
>>>>>> But the code which restore these values during deoptimization was not
>>>>>> updated for XMM registers usage. It assumes that float values were converted
>>>>>> to double on stack as it was before SSE hardware when FPU was used.
>>>>>>
>>>>>> Solution:
>>>>>> Add platform specific method to get float stack value from compiled frame.
>>>>>>
>>>>>> Reviewed by:
>>>>>>
>>>>>> Fix verified (y/n): y, test with -XX:UseSSE=0|1|2
>>>>>>
>>>>>> Other testing:
>>>>>> JPRT
>>>>>>
>