Problem with testN_mem_reg0 in register allocation.

[Lindenmaier, Goetz]

Hi,

we are currently analyzing a bug in our jdk7 VM, which is based on
HS23.  It happens on linux x86_64.
Register allocation tries to spill a RefFlags register, and, as to
expect, fails on this leading to a SIGSEGV.

I suspect this is a strange interdependency between gcm and
register allocation
Gcm produces something as the following pattern (I simplified
to get the essentials).

          Block 35
            Call
            209 testN_mem_reg0
            Catch
       /              \
      /                \
    |/_                _\|
Block 36             Block 146
  ...                 ...
                      159 testP_reg
                      158 jmpCon(212)
     \                   /
      \                 /
      _\|             |/_
        Block 39
          ...
       /              \
      /                \
    |/_                _\|
Block 140              ...
  208 jmpCon(209)



Then call_catch_cleanup() repairs the position of 209.
It adds 1088, 1089 and 1090.


          Block 35
            Call
            Catch
       /              \
      /                \
    |/_                _\|
Block 36               Block 146
  1089 testN_mem_reg0    1088 testN_mem_reg0
  ...                    ...
                         159 testP_reg
                         158 jmpCon(212)
     \                   /
      \                 /
      _\|             |/_
        Block 39
          1090 Phi(1089, 1088)
          ...
       /              \
      /                \
    |/_                _\|
Block 140              ...
  208 jmpCon(1090)

Register allocation now wants to spill the register of 1088.
This is necessary as 159 needs the flag register.

Have you seen such a problem before?
We could envision that one the following 3 behaviors is expected and should get fixed:
1. gcm should place node 209 in Block 140.
2. Register allocation should be able to properly rematerialize the testN_mem_reg0 node (which does allow rematerialization).
   This would require that it recognizes that the Phi merges twice the same value.
3. The matcher should not match this node (which matches on a Load and Cmp)?

Best reagrds,
  Martin & Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130819/6c13cbd5/attachment.html