This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: flow patch for condexec
- To: Aldy Hernandez <aldyh at redhat dot com>
- Subject: Re: flow patch for condexec
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Sat, 24 Feb 2001 12:09:20 +0000
- cc: Fergus Henderson <fjh at cs dot mu dot oz dot au>, gcc-patches at gcc dot gnu dot org, rth at redhat dot com, Richard dot Earnshaw at arm dot com
- Organization: ARM Ltd.
- Reply-To: Richard dot Earnshaw at arm dot com
[I'm a couple of days behind on this list ;-]
> a = a > 5 ? (a < 10 ? 55 : 9) : a;
>
> a will be set to 55 when a > 5 AND a < 10, so if-conversion might compare
> a and 5 on one ccr and a and 10 on another ccr (assuming we have multiple
> ccrs to play around with). Then we might set a 3rd condition code to the
> AND of both of the ccrs. Now, if we have a chip in which comparisons
> between ccrs may yield undefined values, imagine something like this
> happens later on:
>
> (insn 19 (set reg5)) set reg5 unconditionally
> (insn 28 (set ccr99 (compare ccr66 ccr77))) ccr99 may be undefined
> (insn 29 (condexec (eq ccr99 0) (set reg5))) set reg5 on ccr9==0
> (insn 43 (condexec (ne ccr99 0) (set reg5))) use reg5 on ccr9!=0
>
Ug. Sounds a bit like your definition of compare on condition registers
is incorrect. Maybe this is, in effect, what you are already doing, but
can't you extend your comparison space to be similar to the way IEEE
floating point behaves, that is to introduce the "unordered" result as
well? Then you would use LTGT and EQ in the above case.
R.