[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, I don't know if this related to the original issue but in .optimized we
have now:
  # RANGE [irange] unsigned char [0, 1] NONZERO 0x1
  # SR.115_117 = PHI <_119(9), SR.115_121(7)>
  # RANGE [irange] unsigned char [0, 1] NONZERO 0x1
  _119 = MAX_EXPR <1, SR.115_117>;

But that Max is just 1 because the max range of SR.115_117 is 1.


I don't know how that showed up in phiopt4 though.
SR.115_117 != 0 ? SR.115_117 : 1
The code definitely looks worse in GCC 13 compared to GCC 12.

[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
On the trunk we now get:
  _25 = SR.116_117 == 0;
  _27 = (unsigned char) _25;
  _32 = _27 | SR.116_117;

Rather than:
  _119 = MAX_EXPR <1, SR.115_117>;

But we should instead just get:
SR.116_117 | 1

Though that should still be transformed into 1 (will fix that seperately).

I have a quick patch which fixes that, we need to move `a ? zero_one_value :
zero_one_value` part of match.pd below the min/max detection.

[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-08-24
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> On the trunk we now get:
>   _25 = SR.116_117 == 0;
>   _27 = (unsigned char) _25;
>   _32 = _27 | SR.116_117;
> 
> Rather than:
>   _119 = MAX_EXPR <1, SR.115_117>;
> 
> But we should instead just get:
> SR.116_117 | 1
> 
> Though that should still be transformed into 1 (will fix that seperately).
> 
> I have a quick patch which fixes that, we need to move `a ? zero_one_value :
> zero_one_value` part of match.pd below the min/max detection.

The two patches for that.

https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628405.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628404.html

I have not looked into the rest but otherwise confirmed.

[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS 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:6df8dcec7196e42ca2eed69e1ae455bae8d0fe93

commit r14-3485-g6df8dcec7196e42ca2eed69e1ae455bae8d0fe93
Author: Andrew Pinski <apinski@marvell.com>
Date:   Sat Aug 19 17:56:46 2023 -0700

    MATCH: `a | C -> C` when we know that `a & ~C == 0`

    Even though this is handled by other code inside both VRP and CCP,
    sometimes we want to optimize this outside of VRP and CCP.
    An example is given in PR 106677 where phiopt will happen
    after VRP (which removes a cast for a comparison) and then
    phiopt will optimize the phi to be `a | 1` which can then
    be optimized to `1` due to this patch.

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

    Note Similar code already exists in simplify_rtx for the RTL level;
    it was moved from combine to simplify_rtx in r0-72539-gbd1ef757767f6d.
    gcc/ChangeLog:

            * match.pd (`a | C -> C`): New pattern.

[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS 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:d9a0d692ffc6951c5670f54c3f4f17ec64a58600

commit r14-3486-gd9a0d692ffc6951c5670f54c3f4f17ec64a58600
Author: Andrew Pinski <apinski@marvell.com>
Date:   Sat Aug 19 15:30:45 2023 -0700

    MATCH: Move `a ? one_zero : one_zero` matching after min/max matching

    In PR 106677, I noticed that on the trunk we were producing:
    ```
      _25 = SR.116_117 == 0;
      _27 = (unsigned char) _25;
      _32 = _27 | SR.116_117;
    ```
    From `SR.115_117 != 0 ? SR.115_117 : 1`
    Rather than:
    ```
      _119 = MAX_EXPR <1, SR.115_117>;
    ```
    Or (rather)
    ```
      _119 = SR.115_117 | 1;
    ```
    Due to the order of the patterns.

    Committed as approved with the new comment and testcase.
    Bootstrapped and tested on x86_64-linux-gnu with no regressions.

    gcc/ChangeLog:

            * match.pd (`a ? one_zero : one_zero`): Move
            below detection of minmax.

    gcc/testsuite/ChangeLog:

            * gcc.dg/tree-ssa/phi-opt-34.c: New test.