Request for reviews (L): 7063629: use cbcond in C2 generated code on T4
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Aug 4 18:19:42 PDT 2011
http://cr.openjdk.java.net/~kvn/7063629/webrev
7063629: use cbcond in C2 generated code on T4
The code is finally shaped as I want and it passed CTW, regression, nsk tests on
T4 and x86.
Added new fused compare and branch instructions into sparc.ad and corresponding
short versions which use cbcond instruction. Added new flag avoid_back_to_back
to avoid generation of cbcond back to back.
Split shorten_branches() into 2 methods. First method conservatively estimates
code size and branches location and does few rounds of branch shortening. It is
executed before ScheduleAndBundle(). Step 3 is moved to new method
shorten_branches_final() called after ScheduleAndBundle(). It does final
paddings, alignment and final branch replacement. Method fill_buffer() does
verification instead of padding.
Labels are binded now only during code generation in fill_buffer(). As result
they are not available when forward branches are emitted. To fix that
MacroAssembler branch instructions are used now in x86 .ad files. I replaced
unused rtype parameter with maybe_short flag to force using only long branches
in .ad long branch instructions.
Added check to adlc to verify that short version of a branch instructions has
the same declaration in .ad file.
Added assert to verify that the size of emitted instruction matches the value
returned by MachNode::size(). Found that MachBreakpointNode::size() returned
incorrect value on x64.
Fixed loop alignment for Sparc (min alignment should be instruction size which
is 4 bytes instead of 1 byte).
The prototype was done by Tom and I took some of his additional fixes. The block
changes go with some code in output to put opto assembly style block comments in
the PrintNMethods output. There's also snippet in there that deals with the fact
kill projections on branches make it appear the kill occurs after the branch
instead of being part of it.
More information about the hotspot-compiler-dev
mailing list