On Thu, Feb 23, 2017 at 02:26:24PM +0100, Bernd Schmidt wrote:
> On 02/23/2017 12:46 PM, Jakub Jelinek wrote:
> > But as soon as we only have the (unlt (reg:DF 100) (reg:DF 97)),
> > reversed_comparison_code fails on it:
> > case UNLT:
> > case UNLE:
> > case UNGT:
> > case UNGE:
> > /* We don't have safe way to reverse these yet. */
> > return UNKNOWN;
>
> I do have to wonder why. The reverse_condition_maybe_unordered function
> knows how to reverse these, and I can't quite figure out what the problem is
> here. The comment isn't super helpful.
Yeah, and it is very old code, r44846 apparently.
Note that the function returns UNKNOWN not just for these, but also for
GT/GE/LT/LE. If the condition is not canonicalized yet, we hit the
if (GET_MODE_CLASS (mode) == MODE_CC
&& REVERSIBLE_CC_MODE (mode))
return REVERSE_CONDITION (code, mode);
case or
if (GET_MODE_CLASS (mode) == MODE_CC || CC0_P (arg0))
{
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.
> > - && (reversed_comparison_code (if_info->cond, if_info->jump)
> > - != UNKNOWN))
> > + && (if_info->rev_cond
> > + || reversed_comparison_code (if_info->cond,
> > + if_info->jump) != UNKNOWN))
>
> Maybe have a reversed_cond_code (if_info) function? This pattern seems to
> occur a few times.
Ok, will do.
> > @@ -4676,7 +4713,12 @@ find_cond_trap (basic_block test_bb, edg
> > {
> > code = reversed_comparison_code (cond, jump);
> > if (code == UNKNOWN)
> > - return FALSE;
> > + {
> > + cond = noce_get_condition (jump, &cond_earliest, true);
> > + if (!cond)
> > + return FALSE;
> > + code = GET_CODE (cond);
> > + }
>
> This one is an extra optimization, similar but unrelated to the others,
> right?
Yes.
> Can't you figure out the need to reverse a bit earlier and pass it
> into the first noce_get_condition call?
That is indeed possible. Let me adjust the patch.
Jakub
