[Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64

[Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64

[guojiufu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597

            Bug ID: 111597
           Summary: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal
                    for ppc64
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

In match.pd there is a pattern:
/* ((T)(A)) + CST -> (T)(A + CST)  */
#if GIMPLE
  (simplify
   (plus (convert:s SSA_NAME@0) INTEGER_CST@1)
    (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
         && TREE_CODE (type) == INTEGER_TYPE
         && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
         && int_fits_type_p (@1, TREE_TYPE (@0)))
     /* Perform binary operation inside the cast if the constant fits
        and (A + CST)'s range does not overflow.  *

But this pattern seems not in favor of all targets. 
For example, the below code hits this pattern, 

long foo1 (int x)
{
  if (x>1000)
    return 0;
  int x1 = x +1;
  return (long) x1 + 40;                                                        
}

Compile with "-O2 -S", on ppc64le, the generated asm is:
        cmpwi 0,3,1000
        bgt 0,.L3
        addi 3,3,41
        extsw 3,3 ;; this is suboptimal
        blr
        .p2align 4,,15
.L3:
        li 3,0
        blr
--------------
But for the below code, the generated asm seems better: without 
long foo1 (int x)
{
  if (x>1000)
    return 0;
  return (long) x + 40;                                                         
}

        cmpwi 0,3,1000
        bgt 0,.L3
        addi 3,3,40
        blr
        .p2align 4,,15
.L3:
        li 3,0
        blr

[Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64

[guojiufu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597

--- Comment #1 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
While, even without this pattern in match.pd, the generated the sign
extend(extsw) is still there.
So, just wondering if this sub-optimal asm code would be fixed in another way.

[Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it's only because the incoming x is sign-extended to long due to the ABI?
Seems to be a quite "localized" issue.  Btw, it was ppc folks requesting this
pattern as a building block for a larger transform.

It's always difficult to use canonicalizations to do simplifications.

[Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64

[guojiufu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597

--- Comment #3 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
(In reply to Jiu Fu Guo from comment #0)
> In match.pd there is a pattern:
> /* ((T)(A)) + CST -> (T)(A + CST)  */
> #if GIMPLE
>   (simplify
>    (plus (convert:s SSA_NAME@0) INTEGER_CST@1)
>     (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
>          && TREE_CODE (type) == INTEGER_TYPE
>          && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
>          && int_fits_type_p (@1, TREE_TYPE (@0)))
>      /* Perform binary operation inside the cast if the constant fits
>         and (A + CST)'s range does not overflow.  *
> 
> But this pattern seems not in favor of all targets. 
> For example, the below code hits this pattern, 
> 
> long foo1 (int x)
> {
>   if (x>1000)
>     return 0;
>   int x1 = x +1;
>   return (long) x1 + 40;                                                    
> 
> }

For this code, without the pattern "((T)(A)) + CST -> (T)(A + CST)",
the final gimple code is:
  x1_4 = x_3(D) + 1;
  _1 = (long int) x1_4;
  _5 = _1 + 40;

With the pattern,
the final gimple code is:
  _4 = x_2(D) + 41;
  _3 = (long int) _4;

So, this pattern would be "reasonable".