RFR: 8319451: PhaseIdealLoop::conditional_move is too conservative

[Quan Anh Mai]

On Mon, 6 Nov 2023 19:10:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> When transforming a Phi into a CMove, the threshold is set to be approximately BlockLayoutMinDiamondPercentage, the reason is given:
> 
> // BlockLayoutByFrequency optimization moves infrequent branch
> // from hot path. No point in CMOV'ing in such case
> 
> This sets the default value of the threshold to be around 18%, which is too conservative. The reason also does not make a lot of sense since the important property which makes jumping expensive is not code layout. We should remove this.
> 
> Please kindly review, thank you very much.

This is the result of the benchmark running on my machine. The result is consistent with the common knowledge, as the `CMove` version seems to offer better performance when the uncommon path frequency is above 1%.

                                        Before             After
    Benchmark  (freq)  Mode  Cnt    Score     Error    Score    Error  Units
    CMove.run       3  avgt    5  179.402 ±   5.504  181.112 ±  8.658  us/op
    CMove.run       6  avgt    5  191.884 ±  15.271  189.571 ± 11.785  us/op
    CMove.run      10  avgt    5  196.144 ±   8.946  198.864 ±  1.440  us/op
    CMove.run      20  avgt    5  287.090 ± 141.540  198.979 ±  4.015  us/op
    CMove.run      30  avgt    5  353.721 ± 109.473  198.730 ±  2.302  us/op
    CMove.run      60  avgt    5  489.541 ±   4.100  199.645 ±  4.552  us/op
    CMove.run     100  avgt    5  675.543 ±  12.810  199.739 ±  2.202  us/op
    CMove.run     200  avgt    5  199.176 ±   2.957  199.584 ±  2.111  us/op
    CMove.run     300  avgt    5  198.941 ±   2.642  200.112 ±  3.551  us/op
    CMove.run     600  avgt    5  199.266 ±   3.999  199.023 ±  1.202  us/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16524#issuecomment-1796141911