On Thu, Feb 23, 2017 at 03:07:14PM +0100, Jakub Jelinek wrote: > On Thu, Feb 23, 2017 at 02:47:11PM +0100, Bernd Schmidt wrote: > > On 02/23/2017 02:36 PM, Jakub Jelinek wrote: > > > and both UNLT and GE can be reversed. But if the arguments of the > > > condition > > > are canonicalized, we run into: > > > /* Test for an integer condition, or a floating-point comparison > > > in which NaNs can be ignored. */ > > > if (CONST_INT_P (arg0) > > > || (GET_MODE (arg0) != VOIDmode > > > && GET_MODE_CLASS (mode) != MODE_CC > > > && !HONOR_NANS (mode))) > > > return reverse_condition (code); > > > and thus always return UNKNOWN. > > > > So... do you think we could add (in gcc-8, probably, although if it fixes > > this regression...) > > > > else if (GET_MODE (arg0) != VOIDmode > > && GET_MODE_CLASS (mode) != MODE_CC > > && HONOR_NANS (mode)) > > return reverse_condition_maybe_unordered (code); > > > > to make this work? > > Maybe, though I'd feel safer about trying it only in gcc 8. I can certainly > test such a change on a couple of targets. It would not be sufficient, we'd > either need to also reverse_condition_maybe_unordered for the UN* codes > we don't handle yet, or break so that we perhaps reach this spot.
This stuff has been introduced with http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00454.html where the initial submission indeed just returned reverse_condition_maybe_unordered for UNLT etc. but then Richard complained about that: http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00470.html By keeping jump.c as is and just changing ifcvt.c we allow the targets to say what exactly they do support and what is and what isn't reversible through REVERSIBLE_CC_MODE and REVERSE_CONDITION macros. Jakub
