On Fri, 12 Jul 2019, Richard Sandiford wrote:
> At least AIUI, __builtin_isunordered etc. don't raise an exception even
> for signalling NaNs.
__builtin_isunordered should raise "invalid" for signaling NaNs.
(isunordered is the IEEE 754 operation compareQuietUnordered, and IEEE 754
specifies f
Eric Botcazou writes:
>> I'm not sure using flags_to_condition really buys anything then,
>> since you have to think about each individual case to see whether
>> it belongs in the switch or not. I also don't have any proof
>> that the no-op cases are the common ones (since adding this
>> fast pat
> I'm not sure using flags_to_condition really buys anything then,
> since you have to think about each individual case to see whether
> it belongs in the switch or not. I also don't have any proof
> that the no-op cases are the common ones (since adding this
> fast path of course slows down the o
Eric Botcazou writes:
>> No, no trivial paths unfortunately. I'd hoped that inlining and
>> jump threading would give us very similar code, but no such luck.
>> condition_to_flags is a table lookup, but then flags_to_condition
>> is a branch tree.
>
> Too bad. Perhaps this would be an interestin
> No, no trivial paths unfortunately. I'd hoped that inlining and
> jump threading would give us very similar code, but no such luck.
> condition_to_flags is a table lookup, but then flags_to_condition
> is a branch tree.
Too bad. Perhaps this would be an interesting optimization exercise.
> If
Eric Botcazou writes:
>> gcc/
>> * jump.c (FLAGS_EQ, FLAGS_LT, FLAGS_GT, FLAGS_UNORDERED, FLAGS_ORDER)
>> (FLAGS_SIGNED, FLAGS_UNSIGNED, FLAGS_SIGN_AGNOSTIC, FLAGS_SIGNEDNESS)
>> (FLAGS_TRAP_QNANS, FLAGS_TRAP_SNANS, FLAGS_TRAP_NANS, FLAGS_TRAP_NONE)
>> (FLAGS_TRAPS): New consta
> gcc/
> * jump.c (FLAGS_EQ, FLAGS_LT, FLAGS_GT, FLAGS_UNORDERED, FLAGS_ORDER)
> (FLAGS_SIGNED, FLAGS_UNSIGNED, FLAGS_SIGN_AGNOSTIC, FLAGS_SIGNEDNESS)
> (FLAGS_TRAP_QNANS, FLAGS_TRAP_SNANS, FLAGS_TRAP_NANS, FLAGS_TRAP_NONE)
> (FLAGS_TRAPS): New constants.
> (condition_
Eric Botcazou writes:
>> AIUI, neither ORDERED nor UNEQ trap on signalling NaNs. Without this,
>> the follow-on patch would fold
>>
>>(and (ordered x y) (uneq x y)) -> (eq x y)
>>
>> which is the same thing for quiet NaNs but not for signalling NaNs.
>
> Note that GCC defaults to -fno-signa
> AIUI, neither ORDERED nor UNEQ trap on signalling NaNs. Without this,
> the follow-on patch would fold
>
>(and (ordered x y) (uneq x y)) -> (eq x y)
>
> which is the same thing for quiet NaNs but not for signalling NaNs.
Note that GCC defaults to -fno-signaling-nans and the transformation
> AIUI, neither ORDERED nor UNEQ trap on signalling NaNs. Without this,
> the follow-on patch would fold
>
>(and (ordered x y) (uneq x y)) -> (eq x y)
>
> which is the same thing for quiet NaNs but not for signalling NaNs.
I see, thanks for explaining.
--
Eric Botcazou
Eric Botcazou writes:
>> ...trapping on signalling NaNs is enough for the field to be true.
>
> So what's the point in encoding this? The main distinction, and the only one
> relevant for the RTL middle-end, is whether the operator traps on quiet NaNs
> since this can change the comparison inst
> ...trapping on signalling NaNs is enough for the field to be true.
So what's the point in encoding this? The main distinction, and the only one
relevant for the RTL middle-end, is whether the operator traps on quiet NaNs
since this can change the comparison instruction emitted by the back-end
Eric Botcazou writes:
>> +/* Invoke T (CODE, ORDER, SIGNEDNESS, CAN_TRAP) for each comparison, where:
>> +
>> + - CODE is the rtl comparison code
>> + - ORDER is the OR of the conditions under which CODE returns true
>> + - SIGNEDNESS is the signedness of COND, or 0 if it is sign-agnostic
>>
> +/* Invoke T (CODE, ORDER, SIGNEDNESS, CAN_TRAP) for each comparison, where:
> +
> + - CODE is the rtl comparison code
> + - ORDER is the OR of the conditions under which CODE returns true
> + - SIGNEDNESS is the signedness of COND, or 0 if it is sign-agnostic
> + - CAN_TRAP is true if CO
14 matches
Mail list logo
