Re: patch to fix rtl documentation for new floating point comparisons

[Joseph Myers <joseph at codesourcery dot com>]

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
joseph@codesourcery.com