RFR: 8304049: C2 can not merge trivial Ifs due to CastII

[Yi Yang]

On Wed, 15 Mar 2023 10:37:03 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Hi can I have a review for this patch? C2 can not apply Split If for the attached trivial case. PhiNode::Ideal removes itself by unique_input but introduces a new CastII
> 
> https://github.com/openjdk/jdk/blob/e3777b0c49abb9cc1925f4044392afadf3adef61/src/hotspot/share/opto/cfgnode.cpp#L1470-L1474
> 
> https://github.com/openjdk/jdk/blob/e3777b0c49abb9cc1925f4044392afadf3adef61/src/hotspot/share/opto/cfgnode.cpp#L2078-L2079
> 
> Therefore we have two Cmp, which is not identical for split_if.
> 
> ![image](https://user-images.githubusercontent.com/5010047/225285449-b41dc939-1d3f-45f3-b6d6-a9b9445c2f6a.png)
> (Fig1. Phi#41 is removed during ideal, create CastII#58 then)
> 
> ![image](https://user-images.githubusercontent.com/5010047/225285493-30471f1c-97b0-452b-9218-3b5f09f09859.png)
> (Fig2. CmpI#42 and CmpI#23 are different comparisons, they are not identical_backtoback_ifs )
> 
> This patch adds Cmp identity to find existing Cmp node, i.e. Cmp#42 is identity to Cmp#23
> 
> 
>   public static void test5(int a, int b){
>  
>     if( b!=0) {
>       int_field = 35;
>     } else {
>       int_field =222;
>     }
> 
>     if( b!=0) {
>       int_field = 35;
>     } else {
>       int_field =222;
>     }
>   }
> 
> 
> 
> Test: tier1, application/ctw/modules

A safer approach is that we don't optimize it when Cast input carries any dependencies(In such case, I still see hundreds of transformation happen during building)

    Node* uncast = n->uncast();
    if (uncast != n && !n->as_ConstraintCast()->carry_dependency()) {

But this can not solve the above trivial case, because CastII#58 generated in [PhiNode::Ideal](https://github.com/y1yang0/jdk/commit/6961dea52a6aae94d1fb4573de64525f4934352e#diff-8ffaebb53d272c5385ca4d9df21e8bda21133d11ad64d4c4a5ab4c3a3301ce17R1697) carries unnecessarily strong dependency anyway, I wonder if it's possible to make strong dependency only when we have precise pattern described in https://bugs.openjdk.org/browse/JDK-8139771

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

PR: https://git.openjdk.org/jdk/pull/13039