RFR: 8365205: C2: Optimize popcount value computation using knownbits [v8]

[Emanuel Peter]

On Mon, 15 Sep 2025 08:20:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes PopCount value transforms using KnownBits information.
>> Following are the results of the micro-benchmark included with the patch
>> 
>> 
>> 
>> System: 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                      Mode  Cnt       Score   Error  Units
>> PopCountValueTransform.LogicFoldingKerenLong  thrpt    2  215460.670          ops/s
>> PopCountValueTransform.LogicFoldingKerenlInt  thrpt    2  294014.826          ops/s
>> 
>> Withopt:
>> Benchmark                                      Mode  Cnt       Score   Error  Units
>> PopCountValueTransform.LogicFoldingKerenLong  thrpt    2  389978.082          ops/s
>> PopCountValueTransform.LogicFoldingKerenlInt  thrpt    2  417261.583          ops/s
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extending the random ranges

Changes requested by epeter (Reviewer).

test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java line 46:

> 44:     static final int SIZE = 4096;
> 45: 
> 46:     static int rand_numI = G.uniformInts(Integer.MIN_VALUE, Integer.MAX_VALUE).next();

Why not just take `G.ints().next()`?

test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java line 56:

> 54:     static final long rand_bndL2 = G.uniformLongs(-0xFFFFFFL, 0xFFFFFF).next();
> 55:     static final long rand_popcL1 = G.uniformLongs(0, 4).next();
> 56:     static final long rand_popcL2 = G.uniformLongs(0, 32).next();

Can you please give us some code comments why you are doing:
- only uniform distribution. Is that needed? Generators generates special values more often for a good reason: it creates interesting edge cases, especially for bit operations like this here.
- Why are you restricting the ranges? There could always be surprises outside the ranges you pick, and it would be a shame to not generate those. Unless you are absolutely sure they are not needed. Or if extending the range would mean we would generate interesting cases with a probability that is too small, that could be another reason to restrict the ranges.

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

PR Review: https://git.openjdk.org/jdk/pull/27075#pullrequestreview-3227945975
PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2351152244
PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2351166568