http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782
--- Comment #2 from Paulo J. Matos <Paulo.Matos at csr dot com> 2011-02-17
14:56:45 UTC ---
Just a note to this... this bug assumes that cbranch<mode>4 is _not_
implemented. If cbranch<mode>4 is not an optional standard name to implement
then this bug is invalid, but we should document this requirement somewhere.
I just noticed that optabs.h has the comment before can_compare_p:
/* Nonzero if a compare of mode MODE can be done straightforwardly
(without splitting it into pieces). */
extern int can_compare_p (enum rtx_code, enum machine_mode,
enum can_compare_purpose);
By this I assume that cbranch should be implemented if there is an instruction
that performs a compare and branch in one go without ''splitting it into
pieces''. However, by looking at the vax case (which I think it does not have
such an intruction) cbranch is implemented as:
(define_expand "cbranch<mode>4"
[(set (cc0)
(compare (match_operand:VAXint 1 "nonimmediate_operand" "")
(match_operand:VAXint 2 "general_operand" "")))
(set (pc)
(if_then_else
(match_operator 0 "ordered_comparison_operator" [(cc0)
(const_int 0)])
(label_ref (match_operand 3 "" ""))
(pc)))]
"")
which ends up expanding it into multiple insns...
I can do the same on my side. However, that makes cbranch non-optional which is
not-documented and breaks backward compatibility (in the sense that in previous
gcc versions the lack of a cbranch implementation didn't seem to trigger any
strange bug).
