[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe:
(simplify
 (paren (complex_expr @0 @1))
 (complex_expr (paren @0) (paren @1))
(simplify
 (paren (real_expr @0))
 (real_expr (paren @0))
(simplify
 (paren (imag_expr @0))
 (real_expr (paren @0))

Is enough.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Maybe:
> (simplify
>  (paren (complex_expr @0 @1))
>  (complex_expr (paren @0) (paren @1))

That makes the tree larger though ...

But yes, if we have (complex (real (complex@0)) (imag (complex@0))
and the inner complex are wrapped that would help.

> (simplify
>  (paren (real_expr @0))
>  (real_expr (paren @0))
> (simplify
>  (paren (imag_expr @0))
>  (real_expr (paren @0))
> 
> Is enough.

Maybe it's a task for backprop instead?  It at least "feels" similar ...

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjr19 at cam dot ac.uk

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 115563 has been marked as a duplicate of this bug. ***

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note a good testcase for this is (with `-O3 -ffast-math -fopenmp-simd`):
```

subroutine foo(a,n)

  complex (kind(1d0)) :: a(*)
  integer :: i,n

!$OMP SIMD
  do i=1,n
     a(i)=(a(i)+(6d0,1d0))
  enddo

end subroutine foo
```

(from PR 115563).

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I wonder if lower complex should do a better job in the first place:
that is from:
  _9 = _8 + __complex__ (6.0e+0, 1.0e+0);
  _11 = ((_9));
  (*a_7(D))[_6] = _11;

instead of producing:
  _9 = COMPLEX_EXPR <_15, _14>;
  _11 = ((_9));
  _19 = REALPART_EXPR <_11>;
  _20 = IMAGPART_EXPR <_11>;

It should produce:
  _19 = ((_15));
  _20 = ((_24));

Instead. that is expand PAREN_EXPR into its components.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have a patch to tree-complex.cc to better handle PAREN_EXPR . It will fix
both the 465.tonto issue and PR 115563.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the handling of PAREN_EXPR in tree-complex.c has been inefficient since
the tree code was added back in r0-85884-gdedd42d511b6e4 .

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C version of the same:
```
void foo(_Complex float *a, int n)
{
  for(int i = 0; i < n; i++)
  {
    _Complex float t;
    t = a[i];
    t += 6.0;
    t = __builtin_assoc_barrier(t);
    a[i] = t;
  }
}
```

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 58477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58477&action=edit
Patch which I am testing

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:59221dc587f369695d9b0c2f73aedf8458931f0f

commit r15-1508-g59221dc587f369695d9b0c2f73aedf8458931f0f
Author: Andrew Pinski <quic_apinski@quicinc.com>
Date:   Thu Jun 20 15:52:05 2024 -0700

    complex-lowering: Better handling of PAREN_EXPR [PR68855]

    When PAREN_EXPR tree code was added in r0-85884-gdedd42d511b6e4,
    a simplified handling was added to complex lowering. Which means
    we would get:
    ```
      _9 = COMPLEX_EXPR <_15, _14>;
      _11 = ((_9));
      _19 = REALPART_EXPR <_11>;
      _20 = IMAGPART_EXPR <_11>;
    ```

    In many cases instead of just simply:
    ```
      _19 = ((_15));
      _20 = ((_14));
    ```

    So this adds full support for PAREN_EXPR to complex lowering.
    It is handled very similar as NEGATE_EXPR; except creating PAREN_EXPR
    instead of NEGATE_EXPR for the real/imag parts. This allows for
    more optimizations including vectorization, especially with
    -ffast-math.
    gfortran.dg/vect/pr68855.f90 is an example where this could show up.
    It also shows up in SPEC CPU 2006's 465.tonto; though I have not done
    any benchmarking there.

    Bootstrapped and tested on x86_64-linux-gnu with no regressions.

    gcc/ChangeLog:

            PR tree-optimization/68855
            * tree-complex.cc (init_dont_simulate_again): Handle PAREN_EXPR
            like NEGATE_EXPR.
            (complex_propagate::visit_stmt): Likewise.
            (expand_complex_move): Don't handle PAREN_EXPR.
            (expand_complex_paren): New function.
            (expand_complex_operations_1): Handle PAREN_EXPR like
            NEGATE_EXPR. And call expand_complex_paren for PAREN_EXPR.

    gcc/testsuite/ChangeLog:

            * gcc.dg/vect/pr68855.c: New test.
            * gfortran.dg/vect/pr68855.f90: New test.

    Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |15.0
         Resolution|---                         |FIXED

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.