This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/86511] [9 Regression] Unordered comparisons are expanded with branchless code


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86511

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #2)
> It looks like this goes wrong somewhere in expansion which seems to expand
> this as UNORDERED || GE w/o protecting the GE properly.  It looks like we
> do not have optabs for UNGE, but only unord_optab.
> 
> I guess you need to trace expansion to see where it goes wrong (maybe
> it's just a bug in if-conversion...)

This happens in expmed.c, emit_store flag, where the comparison is split using
split_comparison (from dojump.c) to first_code and code.

Following the split, we get to:

      /* Try using a setcc instruction for ORDERED/UNORDERED, followed by a
         conditional move.  */
      tem = emit_store_flag_1 (subtarget, first_code, op0, op1, mode, 0,
                               normalizep, target_mode);
      if (tem == 0)
        return 0;

      if (and_them)
        tem = emit_conditional_move (target, code, op0, op1, mode,
                                     tem, const0_rtx, GET_MODE (tem), 0);
      else
        tem = emit_conditional_move (target, code, op0, op1, mode,
                                     trueval, tem, GET_MODE (tem), 0);

which emits both comparisons via setcc and cmove. For example, UNGE gets split
to UNORDERED and GE, the second one traps.

I don't think the above is correct for trapping math.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]