[Bug rtl-optimization/65651] Redundant cmp with zero instruction in loop for x86 target.

["ysrumyan at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
Jakub,

Thanks for your comments.

We will try to fix this issue ourselves.

Best regards.
Yuri.

P.S. Note that icc does not produce such redundant cmp with zero.

2015-04-01 16:10 GMT+03:00 jakub at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65651
>
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org,
>                    |                            |uros at gcc dot gnu.org
>
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Well, there is a significant difference between the two testcases, one uses the
> result of the comparison just in == 0 test, thus CCZmode is appropriate, the
> other uses it in two comparisons, one == 0 test and one < 0 test.
> For combine to match *sub<mode>_2 insn, it has to match
> ix86_match_ccmode (insn, CCGOCmode)
> where CCGOCmode stands for:
>    Add CCGOC to indicate comparisons against zero that allows
>    unspecified garbage in the Carry and Overflow flag. This
>    mode is used to simulate comparisons of (a-b) and (a+b)
>    against zero using sub/cmp/add operations.
> But the jle instruction tests ZF || SF <> OF and thus it isn't appropriate.
> So the question is if the CCGOC test isn't too restrictive, say if CCGCmode
> would be sufficient (but then we'd still need to arrange for the CCGCmode to be
> used, rather than CCmode), or if the optimization you are looking for is simply
> not possible.
>
> --
> You are receiving this mail because:
> You reported the bug.