This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Restore i?86/x86_64 4.6 and earlier cmov behavior (PR target/54073)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 15 Nov 2012 02:52:22 +0100
- Subject: Re: [PATCH] Restore i?86/x86_64 4.6 and earlier cmov behavior (PR target/54073)
- References: <20121114230852.GO1886@tucnak.redhat.com>
> Hi!
>
> Before Richard Sandiford's 4.7 optab cleanups emit_conditional_move
> wasn't testing the predicate on the comparison, and apparently
> mov<mode>cc patterns in i386.md can handle some comparisons that the
> current predicates on the expanders reject. This PR on MonteCarlo
> kernel shows a hardly predictable floating point UNLT comparison with SImode
> conditional increment, on which cmov improves things a lot.
>
> The following patch restores the 4.6 and earlier behavior, if mov<mode>cc
> isn't able to handle the comparison, it will FAIL (except for the fallout
> discovered during the bootstrap/regtest, that floating point conditional
> move didn't check on i686 -m32 for DImode comparisons).
>
> If cmovs are undesirable on likely well predictable conditionals, we should
> reject it somewhere else, depending on the predictability of the
> conditionals, not based on whether the comparison is ordered or not.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2012-11-14 Jakub Jelinek <jakub@redhat.com>
>
> PR target/54073
> * config/i386/i386.md (mov<mode>cc): Use comparison_operator
> instead of ordered_comparison_operator resp.
> ix86_fp_comparison_operator predicates.
> * config/i386/i386.c (ix86_expand_fp_movcc): Reject TImode
> or for -m32 DImode comparisons.
OK, note that I also have patch in testing to do the same for cbranch and
cstore. I however missed the FP cmove variant.
Thanks!
Honza