On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
> @findex ge
> @cindex greater than
> @@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
> @item (ge:@var{m} @var{x} @var{y})
> @itemx (geu:@var{m} @var{x} @var{y})
> Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
> +If the operands are floating point, @code{ge} is a signaling
> +comparison and corresponds to the IEC 60559
> +@code{compareSignalingGreater} operation. @code{geu} is undefined for
> +floating point numbers.
No, compareSignalingGreaterEqual.
> @findex le
> @cindex less than or equal
> @@ -2610,7 +2629,64 @@ Like @code{gt} and @code{gtu} but test f
> @cindex unsigned less than
> @item (le:@var{m} @var{x} @var{y})
> @itemx (leu:@var{m} @var{x} @var{y})
> -Like @code{gt} and @code{gtu} but test for ``less than or equal''.
> +Like @code{gt} and @code{gtu} but test for ``less than or equal''. If
> +the operands are floating point, @code{le} is a signaling comparison
> +and corresponds to the IEC 60559 @code{compareSignalingLess}
> +operation. @code{leu} is undefined for floating point numbers.
compareSignalingLessEqual.
> +@table @code
> +@findex ltgt
> +@cindex less than or greater than
> +@item (ltgt:@var{m} @var{x} @var{y})
> +@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
> +@var{y} are less, or greater, otherwise 0. This is a quiet operation
> +that applies only to floating point operands and does not have a
> +corresponding IEC 60559 operation.
On GENERIC, the documentation describes some ambiguity: "With the possible
exception of @code{LTGT_EXPR}, all of these operations are guaranteed
not to generate a floating point exception.".
LTGT (RTL code) was added by RTH in
<https://gcc.gnu.org/ml/gcc-patches/2000-01/msg00974.html>. LTGT_EXPR was
added in the thread starting at
<https://gcc.gnu.org/ml/gcc-patches/2004-05/msg01674.html>, wherein RTH
stated "the LTGT rtl code is assumed to trap". The documentation was soon
thereafter changed to have the "possible exception" wording (r82467, which
I can't find any sign of having been posted to gcc-patches so don't know
the rationale).
I don't think it's useful to have the trapping semantics unspecified for a
comparison operation like that. So the question is what's most useful for
LTGT and LTGT_EXPR to do (presumably they should do the same thing). Lots
of existing code in this area seems confused (for example, HONOR_SNANS
should be irrelevant to reversing an equality comparison, as reversing it
will change neither results nor exceptions raised, whether or not
signaling NaNs are involved). But maybe more code treats LTGT as a
signaling operation than otherwise, in accordance with the original
intent, and so that's the most appropriate way to document it (with !UNEQ
being the representation of the corresponding quiet operation).
It's not clear to me that ad hoc logic around particular operations is the
best way of handling optimizations in this area, instead of generic logic
using four bits to track which conditions (< = > unordered) a comparison
is true for and one bit to track whether it raises an exception for
unordered operands. Even if you keep using particular sets of tree / RTL
codes for a subset of operations, maybe transformations that map into and
out of such five-bit form would be more likely to be correct.
--
Joseph S. Myers
jos...@codesourcery.com
