[PATCH, RFC] Handling non-trivial comparisons with cond-exec

[Hans-Peter Nilsson]

On 14 Oct 2003, Alexandre Oliva wrote:

> On Oct 14, 2003, Richard Henderson <rth@redhat.com> wrote:
>
> > On Tue, Oct 14, 2003 at 12:15:16PM +0100, Richard Earnshaw wrote:
> >> * jump.c (any_simple_condjump_p): New function.
> >> * rtl.h: Declare it.
> >> * flow.c (init_propagate_block_info): Only do conditional-execution
> >> processing if the condjump is simple.
>
> > Sounds reasonable.
>
> How about this instead?  It fixes the same problem, but for more ports
> than just arm.
>
> http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00206.html

Cool.  One detail: you don't have to #ifdef HAVE_cc0 anymore.
You can refer to cc0_rtx and use CC0_P unconditionally.  (Lots
of legacy code still does it conditionally.)

On a related note, anyone has a hunch on how close we are to
consider cbranch as a serious alternative to replace cc0 on all
targets, I mean without known performance degradation?

RTH noticed that setcc and cmove needed fixing in
<URL:http://gcc.gnu.org/ml/gcc/2001-01/msg01834.html> and I
mentioned in
<URL:http://gcc.gnu.org/ml/gcc/2001-01/msg01775.html> that there
must be a way to eliminate the cc0-setting insn when condition
codes are set usefully by a previous insn, similar to what's now
handled by NOTICE_UPDATE_CC, usually with the help of insn
attributes.  Filling delay-slots with cc0 setters is also an
issue but I guess I'm the only one worrying about that.

brgds, H-P