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.
- && (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.
@@ -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? Can't you figure out the need to reverse a bit earlier and pass
it into the first noce_get_condition call?
Otherwise ok.
Bernd
