[Bug tree-optimization/104515] [11/12 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-02-14
     Ever confirmed|0                           |1
           Priority|P3                          |P2
          Component|rtl-optimization            |tree-optimization
            Summary|trivially-destructible      |[11/12 Regression]
                   |destructors interfere with  |trivially-destructible
                   |loop optimization - maybe   |destructors interfere with
                   |related to lifetime-dse.    |loop optimization - maybe
                   |                            |related to lifetime-dse.
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Target Milestone|---                         |11.3

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The issue is that store motion of v_7(D)->end cannot be performed
on

  <bb 3> [local count: 955630225]:
  # i_13 = PHI <i_10(6), 0(5)>
  _1 = v_7(D)->end;
  _2 = _1 + 18446744073709551612;
  v_7(D)->end = _2;
  MEM[(T *)_1 + -4B] ={v} {CLOBBER};   // <- inserted by -flifetime-dse
  i_10 = i_13 + 1;
  if (n_6(D) > i_10)
    goto <bb 6>; [89.00%]
  else
    goto <bb 4>; [11.00%]

  <bb 6> [local count: 850510901]:
  goto <bb 3>; [100.00%]

With GCC 10 we didn't have this particular CLOBBER and at least in GCC 10 the
first testcase was properly optimized.

Note there's a dependence on the value of v_7(D)->end for the clobber so
the clobber itself cannot be moved out of the loop.  So the only option
here would be to drop it if it enables store-motion.

We remove all *ssaname_N ={v} {CLOBBER} stmts during the fold-all-builtins
pass but that's very late, in particular _after_ the last CDDCE.  I suspect
that instead of

      NEXT_PASS (pass_dse);
      NEXT_PASS (pass_cd_dce, true /* update_address_taken_p */);
      /* After late CD DCE we rewrite no longer addressed locals into SSA
         form if possible.  */
      NEXT_PASS (pass_forwprop);
      NEXT_PASS (pass_phiopt, false /* early_p */);
      NEXT_PASS (pass_fold_builtins);

we might consider doing FAB (or the CLOBBER removal part) after the last
DSE (or simply direct that last DSE pass do that, with some pass specific
flag).  Note that's still too late since we need store-motion here.

Doing the *ssaname_N ={v} {CLOBBER} clobber removal after the _first_
DSE after IPA inlining would be another option.  Likewise of course
removing it as part of SM as said above.

I can see how easy it is to do from store-motion.