[Bug rtl-optimization/109311] New: [13 Regression] bb_is_just_return miss to realize some bb from r13-6873-g776a5bb5894315

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

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

            Bug ID: 109311
           Summary: [13 Regression] bb_is_just_return miss to realize some
                    bb from r13-6873-g776a5bb5894315
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

Commit r13-6873-g776a5bb5894315 changed BB insns walking order under the
assumption that the handlings in the loop is order independent. But
unfortunately some failures shows it's not.

For a BB:

   15: L15:
   20: NOTE_INSN_BASIC_BLOCK 5
   19: use %3:SI
   32: NOTE_INSN_EPILOGUE_BEG
   33: simple_return
;;  succ:       EXIT

Previously function bb_is_just_return would return true while now it returns
false, since backward walking will meet return insn first, the USE insn isn't
considered as one use to be in *use but instead is taken as unexpected insn
then return false.

By adjusting it not to check !*ret for use can workaround it, 

         if (!*ret && ANY_RETURN_P (pat))
           *ret = insn;
-        else if (!*ret && !*use && GET_CODE (pat) == USE
+        else if (!*use && GET_CODE (pat) == USE
             && REG_P (XEXP (pat, 0))
             && REG_FUNCTION_VALUE_P (XEXP (pat, 0)))
           *use = insn;

but I'm not sure if there is some reason to check both !*ret && !*use, such as
to exclude something like:

    simple_return
    use %3:SI