[Bug c++/97464] New: Missed redundant store optimization opportunity

[Bug c++/97464] New: Missed redundant store optimization opportunity

[pdimov at gmail dot com]

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

            Bug ID: 97464
           Summary: Missed redundant store optimization opportunity
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdimov at gmail dot com
  Target Milestone: ---

The code

    void f( int& x, float& y )
    {
        ++x;
        y = 1;
        --x;
    }

compiles to

    f(int&, float&):
        mov     eax, DWORD PTR [rdi]
        mov     DWORD PTR [rsi], 0x3f800000
        mov     DWORD PTR [rdi], eax
        ret

(https://godbolt.org/z/so4h3v)

but the load from, and the store to, [rdi] are redundant. It's obvious that
TBAA is active, but it for some reason doesn't go far enough.

This is a simplified example from "realer" code where x is a reference count
whose unnecessary manipulations could have been optimized out entirely.

[Bug tree-optimization/97464] Missed redundant store optimization opportunity

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |rguenth at gcc dot gnu.org
          Component|c++                         |tree-optimization
           Keywords|                            |alias, missed-optimization
   Last reconfirmed|                            |2020-10-19

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
In GCCs memory model x and y can still point to the same memory, the only
thing that hints at this not being the case is the load from x at the
--x; statement but we're eliminating this load (using TBAA) with the
store from the ++x statement which means we get to see (at the store
elimination phase)

  int tem = x;
  y = 1;
  x = tem;

and here the store to x is necessary because x and y may now point
to the same storage, each ending lifetime of the int/float object
eventually live previously at the location.

So yes, before eliminating dead code after eliminating redundancies
we could have seen the store is not necessary (actually we still don't
use the present load to do so).

So, it's a difficult one.  And I believe we have a duplicate report somewhere.

[Bug tree-optimization/97464] Missed redundant store optimization opportunity

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |88854
   Last reconfirmed|2020-10-19 00:00:00         |2021-8-14
           Severity|normal                      |enhancement

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> And I believe we have a duplicate report somewhere.

Yes I suspect it is the same as PR 88854.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88854
[Bug 88854] redundant store after load that would makes aliasing UB