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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 42566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42566&action=edit
gcc8-pr82913.patch

Untested fix.
The problem is that we have:
(insn 9 59 10 2 (parallel [
            (set (reg:DI 0 ax)
                (zero_extend:DI (plus:SI (reg:SI 0 ax [107])
                        (const_int 1 [0x1]))))
            (clobber (reg:CC 17 flags))
        ]) "pr82913.c":7 219 {addsi_1_zext}
     (nil))
...
(insn 14 13 23 2 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:SI 0 ax [orig:90 _8 ] [90])
            (const_int 0 [0]))) "pr82913.c":14 3 {*cmpsi_ccno_1}
     (nil))
(insn 23 14 24 2 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:DI 0 ax [orig:95 <retval> ] [95])
            (const_int 0 [0]))) "pr82913.c":16 4 {*cmpdi_ccno_1}
     (nil))
and we record insn 9 as cmp 23's in_a_setter when it is single_set.  But then
try_eliminate_compare on the cmp 14 turns it into a cmp+zext plus and suddenly
when processing cmp 23 it is no longer a single_set.  By readding this guard we
end up with what we used to do, in this particular case it would need further
analysis to do something better (find out that because the comparison consumer
is a NZ test that we could just reuse the SImode comparison, as the zero
extension doesn't affect it; if the comparison was e.g. DImode and we'd test
the sign bit, that wouldn't be true).

Reply via email to