Strange branching performance (original) (raw)

Martin Grajcar maaartinus at gmail.com
Sat Feb 8 13:11:56 PST 2014

Hi Vladimir!

On Sat, Feb 8, 2014 at 4:36 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com>wrote:

Hi Martin,

Your observation is correct. The corresponding code is next: float infrequentprob = PROBUNLIKELYMAG(3); // 0.001 // BlockLayoutByFrequency optimization moves infrequent branch // from hot path. No point in CMOV'ing in such case (110 is used // instead of 100 to take into account not exactness of float value). if (BlockLayoutByFrequency) { infrequentprob = MAX2(infrequentprob, (float) BlockLayoutMinDiamondPercentage/110.0f); } // Check for highly predictable branch. No point in CMOV'ing if // we are going to predict accurately all the time. if (iff->prob < infrequentprob ||_ _iff->prob > (1.0f - infrequentprob)) return NULL; Note, BlockLayoutMinDiamondPercentage is default 20 so infrequentprob become 0.2 as you observed.

Yes, there's a sharp edge somewhere below 0.2.

C2 moves infrequent code outside the loop (with branches out and back) to

keep only hot code inside.

To me it looks like there's nothing to be moved outside of the loop. Mainly because you'd hardy save anything as you'd replace the two instructions

LEA (%result_reg, 1), %tmp_reg CMOVEQ %tmp_reg, %result_reg

by a conditional jump. Saving a single instruction on the hot path and risking a branch misprediction penalty might make sense for very low probabilities like PROB_UNLIKELY_MAG(3), not 20%.

It looks like it does not happen in your case and I need to look why. There

are several conditions besides BlockLayoutByFrequency and the above code could be incorrect and needs to be fixed (or removed).

Nice that you can look into it. There are a lot of attempts to eliminate branching manually like in http://grepcode.com/file/repo1.maven.org/maven2/com.google.guava/guava/15.0/com/google/common/math/IntMath.java#IntMath.gcd%28int%2Cint%29 but this is nearly always less efficient than using CMOVcc.

Regards, Martin. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140208/c635276e/attachment.html

More information about the hotspot-compiler-dev mailing list