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

[Tom Rodriguez]

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
>