Strange branching performance

[Martin Grajcar]

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 infrequent_prob = PROB_UNLIKELY_MAG(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) {
>     infrequent_prob = MAX2(infrequent_prob, (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 < infrequent_prob ||
>       iff->_prob > (1.0f - infrequent_prob))
>     return NULL;
>
> Note, BlockLayoutMinDiamondPercentage is default 20 so infrequent_prob
> 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