[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

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

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.