RFR: 8319451: PhaseIdealLoop::conditional_move is too conservative

Claes Redestad redestad at openjdk.org
Thu Nov 9 14:36:00 UTC 2023


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.

Nice, especially the property that run-to-run variance drops in the 1-20% range. 

@TobiHartmann told me he'll review and that he has queued up a batch of benchmarks to evaluate this change more widely.

test/micro/org/openjdk/bench/vm/compiler/CMove.java line 40:

> 38: 
> 39:     @Param({"3", "6", "10", "20", "30", "60", "100", "200", "300", "600"})
> 40:     int freq;

That `freq` is expressed in "occurrences per thousand" was only obvious after reading the code - perhaps a probability between 0 and 1 (with the appropriate adjustment to `r.nextFloat() < freq` below) would be slightly more intuitive?
Suggestion:

    @Param({"0.003", "0.006", "0.01", "0.02", "0.03", "0.06", "0.1", "0.2", "0.3", "0.6"})
    float freq;

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

PR Review: https://git.openjdk.org/jdk/pull/16524#pullrequestreview-1722679005
PR Review Comment: https://git.openjdk.org/jdk/pull/16524#discussion_r1388087404


More information about the hotspot-compiler-dev mailing list