https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #7 from Richard Henderson <rth at gcc dot gnu.org> --- (In reply to Jiong Wang from comment #5) > although there is no correctness issue with the "if (_27 <= 0)", but I think > for boolean type "<= 0" is exactly "== 0", so the "<" is uncessary. True, but at some point in the optimization of this function it wasn't "<= 0" but "<= variable", which made a lot more sense. > and in this testcase, "_27" happen to be a CCMP candidate, while CCMP code > in aarch64 backend is with the assumption that only EQ/NE comparison will > happen on it. in the bottom of aarch64_get_condition_code_1, if comp_cond is > not NE/EQ, then -1 always returned. So, I think we should treate LE/LEU as > EQ? No, see above. If we hadn't propagated the 0, we really would be asking X <= Y, which is nice shorthand for Y | !X. It would be good if when we folded variable to 0, that we also simplify the condition, but that's really unrelated. > the second is in do_compare_and_jump in dojump.c, we should use GET_MODE > (op0) to get the mode passed to do_compare_rtx_and_jump instead of use > TYPE_MODE (type) ? No, there's a large layering violation going here between expand and do_compare_rtx_and_jump. We ought not return a value of an incorrect mode from expand_normal in the first place. If we need to do something at the do_compare_and_jump level to emit branches using the CCmode... so be it. But don't split this logic across multiple functions at multiple levels. I suspect that we don't need to special case this at all. I suspect that we can emit a setcc, and then a branch off of that, and then have the setcc and branch merge during combine.
