> 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 <ja...@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
