[Bug rtl-optimization/104515] New: trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

["gcc at rabensky dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 104515
           Summary: trivially-destructible destructors interfere with loop
                    optimization - maybe related to lifetime-dse.
           Product: gcc
           Version: og11 (devel/omp/gcc-11)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at rabensky dot com
  Target Milestone: ---

This issue started in GCC-9.1, but a change in GCC-11 made it worse.

It didn't exist in GCC-7.1-GCC-8.5

Short description:
-----------------

When we have a loop that can be optimized out, calling the destructor for a
trivially-destructible type will prevent the optimization starting from GCC-9.1

These are loops that correctly optimized out in GCC-7.1 to GCC-8.5

This bug doesn't happen if we set -fno-lifetime-dse

Interestingly enough - a non-trivially-destructible destructor doesn't
necessarily prevent the optimization.

How this became worse in GCC-11:
-------------------------------

In GCC-11 this also applies to calling the destructor of basic types (int, long
etc.)

So loops that optimized in GCC-7.1 to GCC-10.3 no longer optimize.

Short reproducing example:
-------------------------

NOTE: No `include`s are needed

```
using T = int;
struct Vec {
  T* end;
};
void pop_back_many(Vec& v, unsigned n) {
  for (unsigned i = 0; i < n; ++i) {
    --v.end;
    v.end->~T();
  }
}
```
compiled with `-O3 -Wall`

In GCC-7 to GCC-10, `pop_back_many` optimizes out the loop (becomes
`v.end-=n`).
In GCC-11, the loop remains.

See https://godbolt.org/z/vTexxhxP9

NOTE that adding `-fno-lifetime-dse` will re-enable the loop optimization.

Why this matters
----------------
This prevents optimization of a loop over `std::vector<int>::pop_back()`, which
is a very common usecase!

Loops that optimize out in GCC-7.1 to GCC-10.3 will suddenly not optimize in
GCC-11.1/2, making existing code run MUCH slower! (O(n) instead of O(1))

NOTE: std::vector<int>::resize is a lot slower than loop over pop_back. A loop
over pop_back is currently the most efficient way to do pop_back_many!

More complete reproducing example:
---------------------------------

- We can replace the type `T` with a class that is trivially destructible.
**In that case, the problem exists in previous versions of GCC as well**

- We can replace the type `T` with a class that had user-supplied destructor.
**In that case, the loop correctly optimizes out if possible**

Actual examples:
https://godbolt.org/z/7WqTPq3cE

compiled with `-O3 -Wall`
```
template <typename T>
struct Vec {
  T* end;
};

template <typename T>
void pop_back_many(Vec<T>& v, unsigned n) {
  for (unsigned i = 0; i < n; ++i) {
    --v.end;
    v.end->~T();
  }
}

struct TrivialDestruct {
    ~TrivialDestruct()=default;
};

struct NoopDestruct {
    ~NoopDestruct(){}
};

unsigned count=0;
struct CountDestruct {
    ~CountDestruct(){++count;}
};

// Here loop optimization fails in GCC-11.1-11.2
// But succeeds in GCC 7.1-10.3
//
// NOTE that adding -fno-lifetime-dse re-enabled the optimization
template void pop_back_many(Vec<int>&, unsigned);
// Here loop optimization fails in GCC-9.1-11.2
// But succeeds in GCC 7.1-8.5
//
// NOTE that adding -fno-lifetime-dse re-enabled the optimization
template void pop_back_many(Vec<TrivialDestruct>&, unsigned);
// Here loop optimization succeeds in all versions
//
// NOTE that it's surprising that a no-op destructor can be optimized
// but a trivial destructor can't
template void pop_back_many(Vec<NoopDestruct>&, unsigned);
// Here loop optimization succeeds in all version
//
// NOTE that it's surprising that a destructor with an action
// can be optimized, but a trivial destructor can't
template void pop_back_many(Vec<CountDestruct>&, unsigned);
```