On Thu, May 3, 2018 at 10:39 AM, Kyrill  Tkachov
<kyrylo.tkac...@foss.arm.com> wrote:
>
> On 02/05/18 17:45, Wilco Dijkstra wrote:
>>
>> Richard Biener wrote:
>>
>>> why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with
>>> UNORDERED_EXPR?  Note again that might trap/throw with -fsignalling-nans
>>> so better avoid this transform for flag_signalling_nans as well...
>>
>> Both currently trap on signalling NaNs due to the implementation of the
>> C99
>> builtins being buggy (PR66462).
>>
>> However since the inputs are results of FP operations, they are guaranteed
>> to be quiet NaNs in this case, so no extra test for signalling NaNs is
>> required.
>
>
> I'm happy to remove the check on flag_signaling_nans from the patch.

The issue is not actual runtime behavior but GIMPLE IL sanity.  We force
possibly trapping compares out of conditions:

double x;
int main()
{
  try {
      if (__builtin_isunordered (x, x))
         __builtin_abort ();
  } catch (...) {
  }
}

with -fsignaling-nans -fnon-call-exceptions you get

      _3 = x.1_1 unord x.2_2;
      if (_3 != 0) goto <D.2364>; else goto <D.2365>;

while without either it is

      if (x.1_1 unord x.2_2) goto <D.2364>; else goto <D.2365>;

I'm not sure it actually matters here - at least on GIMPLE there's no
later sanity-checking on this.  So maybe you can remove the condition
(but please quickly try a testcase with -fnon-call-exceptions and
-fsignaling-nans
and an EH tree - I suppose you hit the stmt_can_throw_internal case once you
have some EH handlers here).

+         rr = create_tmp_var (inner_type);
+         rr = make_ssa_name (rr);
+         ri = create_tmp_var (inner_type);
+         ri = make_ssa_name (ri);

just use

   rr = make_ssa_name (inner_type);
   ri = make_ssa_name (inner_type);

Otherwise OK.

Thanks,
Richard.

> Kyrill
>
>
>>> Which also means that we can dispatch to this simple variant not only for
>>> flag_complex_method != 2 but for !HONOR_NANS && !HONOR_INFINITIES?
>>> Maybe that should be done as followup.
>>
>> With -ffinite-math-only the isunordered will be optimized anyway. So it's
>> just
>> to avoid generating unnecessary dead code.
>>
>> Wilco
>
>

Reply via email to