[Bug tree-optimization/109483] Unoptimal uncprop with assembler flag output

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-04-12
            Summary|Unoptimal jump threading    |Unoptimal uncprop with
                   |with assembler flag output  |assembler flag output
     Ever confirmed|0                           |1
          Component|middle-end                  |tree-optimization

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We expand from

  __asm__ __volatile__("int3" : "=@ccz" success_4);
  if (success_4 != 0)
    goto <bb 4>; [66.00%]
  else
    goto <bb 5>; [34.00%]
;;    succ:       5 
;;                4

;;   basic block 4, loop depth 0
;;    pred:       3
;;                2
  __asm__ __volatile__("" :  :  : "memory");
;;    succ:       5

;;   basic block 5, loop depth 0
;;    pred:       3
;;                4
  # _1 = PHI <success_4(3), 1(4)>
  return _1;

and it's not PHI-opt "getting in the way" but instead RTL expansion
placing the edge 3->4 copy of 'success_4' before the conditional branch
rather than to a new BB.  I suppose if we'd split critical edges that
would fix it (at the expense of some extra blocks and unconditional
jumps).

Note that clang seems to propagate the constant equivalence which we
instead un-propagate.  With -fdisable-tree-uncprop1 you'll get the
expected code:

foo:
.LFB0:
        .cfi_startproc
        cmpl    $-1, %edi
        je      .L8
.L2:
        movl    $1, %eax
        ret
        .p2align 4,,10
        .p2align 3
.L8:
        xorl    %eax, %eax
#APP
# 6 "t.c" 1
        int3
# 0 "" 2
#NO_APP
        je      .L2
        ret

what uncprop doesn't understand is that copying success requires to
materialize it (it's just in CC), that's the reason it prefers that
over a zero (because zero also needs materializing).

And the RTL pipeline is not good enough in scheduling/sinking a
CC consumer across another CC consumer it seems (or even realizing
the result is constant on the only needed edge).

It might be possible to just special-case (bool) ASM defs in uncprop,
but that would be a heuristic.  Not sure if we can portably identify
CC mode constraints.