This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, RFC] Handling non-trivial comparisons with cond-exec
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, <Richard dot Earnshaw at arm dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 15 Oct 2003 09:19:09 -0400 (EDT)
- Subject: Re: [PATCH, RFC] Handling non-trivial comparisons with cond-exec
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