This is the mail archive of the gcc-patches@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]

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


On 02/09/2015 06:24 PM, Joseph Myers wrote:
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.

oops

  @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.
oops again
+@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).
section 7.12.14.4 in C99 seems pretty much to say that this is a quiet operation.

The islessgreater macro determines whether its first argument is less than or greater than its second argument. The islessgreater(x, y) macro is similar to
(x) < (y) || (x) > (y); howev er, islessgreater(x, y) does not raise
the ‘‘invalid’’ floating-point exception when x and y are unordered (nor does it evaluate x
and y twice).
So i think that it seems that we should be pretty safe saying it is quiet.


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.

I will work on the tree version tomorrow and resubmit.

Kenny




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