[Bug target/94857] Failure to optimize load+add+store into add on memory when getting carry flag afterwards on x86

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-04-30
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Likely because we expand from

  u_4 = *p_3(D);
  _8 = .ADD_OVERFLOW (u_4, x_5(D));
  _1 = REALPART_EXPR <_8>;
  _9 = IMAGPART_EXPR <_8>;
  *p_3(D) = _1;
  _7 = _9 != 0;
  return _7;

and add-overflow expansion does not know how to use the TERed u_4.  The
pattern is the following and allows memory:

(define_insn "*add<mode>3_cc_overflow_1"
  [(set (reg:CCC FLAGS_REG)
        (compare:CCC
            (plus:SWI
                (match_operand:SWI 1 "nonimmediate_operand" "%0,0")
                (match_operand:SWI 2 "<general_operand>" "<r><i>,m"))
            (match_dup 1)))
   (set (match_operand:SWI 0 "nonimmediate_operand" "=<r>m,<r>")
        (plus:SWI (match_dup 1) (match_dup 2)))]
  "ix86_binary_operator_ok (PLUS, <MODE>mode, operands)"
  "add{<imodesuffix>}\t{%2, %0|%0, %2}"
  [(set_attr "type" "alu")
   (set_attr "mode" "<MODE>")])

but maybe the alternatives are mixed up here in the different insn parts
of the parallel ...