JDK-6552204 : split_thru_phi leaves behind Phi of AddP which produces inefficient code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2007-05-01
  • Updated: 2010-09-24
  • Resolved: 2007-05-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs10Fixed
Related Reports
Relates :  
JDK-6579652 - repair to split_through_phi breaks AddPNode::Base invariant
Relates :  
JDK-6709742 - find_base_for_derived's use of Ideal NULL is unsafe causing crashes during register allocation
Relates :  
JDK-6614100 - EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea
Description
split_thru_phi and friends will attempt to push memory operations up through phis by pushing all their inputs up first.  If a memory op isn't pushed through then we are left with patterns like (Phi (AddP base #8) (AddP base2 #8)).  These cause the computation of address to occur as a Phi instead of being folded into the addressing mode, which tend to keep an extra register live and will keep us from using implicit null checks on the memory operations.  For example you get this code:

53a   B91: #    B170 B92 <- B90  Freq: 6700.85
53a     INC    [EBP + #8] ! Field java/util/AbstractList.modCount
53d     TEST   EAX,EAX
53f     Jeq    B170  P=0.000001 C=-1.000000
53f
545   B92: #    B94 B93 <- B91  Freq: 6700.84
545     MOV    EDI,[EBP + #12] ! Field java/util/ArrayList.size
548     LEA    EDX,[EAX + #8]
54b     MOV    EBX,[EDX]

instead of this:

53a   B91: #    B170 B92 <- B90  Freq: 6700.85
53a     INC    [EBP + #8] ! Field java/util/AbstractList.modCount
53d     MOV    EBX,[ECX + #8]
540     NullCheck ECX
540
540   B92: #    B94 B93 <- B91  Freq: 6700.84
540     MOV    EDI,[EBP + #12] ! Field java/util/ArrayList.size
Comments
SUGGESTED FIX Original workspace: smite:/export/ws/6552204 Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/c2_baseline Submitter: never PRT data: /net/prt-web.sfbay/prt-workspaces/20070502114532.never.6552204 Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070502114532.never.6552204/ Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070502114532.never.6552204/workspace/webrevs/webrev-2007.05.02/index.html Fixed 6552204: split_thru_phi leaves behind Phi of AddP which produces inefficient code split_thru_phi and friends will attempt to push memory operations up through phis by pushing all their inputs up first. If a memory op isn't pushed through then we are left with patterns like: (Phi (AddP base #8) (AddP base2 #8)) These cause the computation of addresses to occur as a Phi instead of being folded into the addressing mode, which tends to keep an extra register live and will keep us from using implicit null checks on the memory operations involved. For example you currently get this code: 53a B91: # B170 B92 <- B90 Freq: 6700.85 53a INC [EBP + #8] ! Field java/util/AbstractList.modCount 53d TEST EAX,EAX 53f Jeq B170 P=0.000001 C=-1.000000 53f 545 B92: # B94 B93 <- B91 Freq: 6700.84 545 MOV EDI,[EBP + #12] ! Field java/util/ArrayList.size 548 LEA EDX,[EAX + #8] 54b MOV EBX,[EDX] instead of getting this: 53a B91: # B170 B92 <- B90 Freq: 6700.85 53a INC [EBP + #8] ! Field java/util/AbstractList.modCount 53d MOV EBX,[ECX + #8] 540 NullCheck ECX 540 540 B92: # B94 B93 <- B91 Freq: 6700.84 540 MOV EDI,[EBP + #12] ! Field java/util/ArrayList.size A more complex fix would be to rework split_thru_phi to be smarter about how it pushes operations through but split_thru_phi is complex enough that it doesn't seem worth it to fix this problem. The fix I'm proposing it to teach PhiNode::Ideal to repair this. This doesn't seem to affect performance at all. http://javaweb.sfbay/~never/webrev/6552204 Reviewed by: nips, sgoldman, kvn Fix verified (y/n): y refworkload
02-05-2007
EVALUATION A more complex fix would be to rework split_thru_phi to be smarter about how it pushes operations through but split_thru_phi is complex enough that it doesn't seem worth it to fix this problem. The fix I'm proposing it to teach PhiNode::Ideal to repair this.
01-05-2007