Request for reviews (S): 6880034 for HS16 and HS17

[John Rose]

I believe the only sane way to number the 32-bit halves of 64-bit  
values is with some sort of consistently applied rule.  Given that  
goal, the most consistent rule is to appeal first to memory storage  
order (first word then second word in memory layout) and project that  
order into the register file.  This means arithmetic order is  
irrelevant to naming conventions, since the "high" word is the first  
word on big-endian systems, but the second word in x86, etc.

The present fix is a good cleanup which makes register numbering more  
consistent.  (Historically, the SPARC code of HotSpot was ported from  
x86, where an arithmetic low-order word is also the memory first-order  
word.  On Intel you can be sloppy about which is the "high word", but  
on a big-endian machine you cannot.  The SPARC code still has some  
traces of sloppiness.)  Note that the integer registers are still  
inconsistently numbered from this viewpoint.

In order to cope with a buggy choice of subword numbering, we have (in  
the past) debugged our way to a bunch of local fixes where the words  
are swapped as needed, at each use point.  Doing a cleanup like this  
might have a bug tail (which is why we haven't been eager to attempt  
it).  The bug tail, if it exists, will manifest in further stack  
walker or deoptimization bugs where words get swapped, and (upon  
examination) the swapping code can be simply deleted, given the more  
rational numbering scheme.

This is the right time to do such cleanups.  Thanks!

-- John

On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote:

>
> http://cr.openjdk.java.net/~kvn/6880034/webrev.01
>
> Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit- 
> SPARC
>
> Problem (found and described by Volker Simonis):
>  Wrong numbering of the 16 upper double registers in sparc.ad
> maps the invalid half (R_D32x, R_D34x, ..) of the double
> registers F32-F62 to even VMReg numbers (96, 98, ..) and the valid
> part (R_D32, R_D34, ..) to odd VMReg numbers (97, 99, ..). Later on,
> when the locals array for the safepoint is constructed in
> Compile::FillLocArray(), the call to OptoReg::as_VMReg(regnum) for a
> valid, even double register >= F32 (e.g. 96) returns the invalid, odd
> part (e.g. 97). This odd VMReg number is than stored in the Location
> part of the local and leads to the the fact that reg->reg2stack()
> returns odd values for float registers >= F32.
> This finally leads to a BUS error due to an unaligned double read
> when the location of the register is accessed through the reg_map
> during deoptimisation in StackValue::create_stack_value().
>
> Solution:
> Fix the double register encodings in sparc.ad.
> Use FloatRegisterImpl::number_of_registers instead of 64
> in RegisterSaver::save_live_registers() and restore_live_registers().
> Replace if(true) with comments in save_live_registers().
>
> Contributed by: volker.simonis at gmail.com
>
> Reviewed by:
>
> Fix verified (y/n): y, bug's test
>
> Other testing:
> JPRT, CTW
>