RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y" [v2]

[Andrew Haley]

On Wed, 9 Feb 2022 16:04:48 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
>> 
>> The results of the microbenchmark are as follows:
>> 
>> Baseline:                                                                                                                                         
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ± 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ± 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ± 0.007  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ± 0.004  ns/op
>> 
>> Patch:
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ± 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ± 0.005  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ± 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ± 0.004  ns/op
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include bug id.

> I am not clear whether there is a justification for pushing this change. We are in danger of heading down the garden path looking for optimization fairies.
> 
> n.b. the fact that gcc and clang do this is not really a good argument. In Java the trade-off is one runtime cost against another which is not the case for those compilers.

I agree. If we're dong this kind of optimization it makes little sense to do it piecemeal. Maybe, just maybe, there's some opportunity for some more general boolean simplification, but even then it's not clear how much of it is worth doing.

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

PR: https://git.openjdk.java.net/jdk/pull/7395