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

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 17 Feb 2015, Kenneth Zadeck wrote:

> On 02/17/2015 07:05 AM, Joseph Myers wrote:
> > On Tue, 17 Feb 2015, Richard Earnshaw wrote:
> > 
> > > So the problem we have today is the compiler has no way to distinguish
> > > between, say, < and __builtin_isless.  According to Annex F (c99) the
> > > former should be signalling while the latter quiet.
> > We do have a way: < is LT and __builtin_isless is !UNGE.
> > 
> > __builtin_islessgreater is !UNEQ.  The question is whether it's also LTGT
> > or whether LTGT means LT || GT.  And the existing documentation of
> > LTGT_EXPR leaves this unspecified, which seems clearly unhelpful.  Either
> > way, you have existing code in GCC that's incorrect (i.e. that does not
> > correspond to the set of transformations that are actually valid for the
> > chosen semantics).
> > 
> Having spent the majority of my gcc life at the rtl level, i find it
> astonishing that the designers of the tree level allowed this machine
> dependency to get into what i was always told was a pristine machine
> independent pass.    i would have thought that the at the tree level this
> could/should be nailed down to being quiet and if someone wanted to support a
> noisy version in their port, then they would look for lt || gt when converting
> to the rtl level which has never been so pristine.

As I said in <https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00583.html>, I 
can't find any posting to gcc-patches of the r82467 commit that introduced 
the "possible exception" wording.

> it would be nice to know exactly how many ports (if any) actually have a noisy
> version of this in hardware. ltgt is not a common primitive (it is not even
> mentioned in the ieee fp standards).

For example, on MIPS the C.cond.fmt instruction has a four-bit condition 
field: "In the cond field of the instruction: cond 2..1 specify the nature 
of the comparison (equals, less than, and so on); cond 0 specifies whether 
the comparison is ordered or unordered, i.e. false or true if any operand 
is a NaN; cond 3 indicates whether the instruction should signal an 
exception on QNaN inputs, or not".  Together with possibly negating the 
result you get all 32 possible comparisons (choice of whether the 
comparison is true or false for each of = < > unordered, choice of whether 
to raise invalid for quiet NaNs).

> > I think the main difficulty in proper Annex F support would be making
> > optimizers (on each IR) understand the side-effects operations have in
> > terms of raising exceptions, and how operations may take the rounding mode
> > or existing exceptions raised as inputs - with an associated issue of
> > defining the existing default floating-point rules well enough to keep a
> > default mode that doesn't unduly inhibit optimization.
> i have been thinking a lot about the rounding modes.    the only way that
> could think about properly supporting them was to actually add new rtl and
> tree operations that take the rounding mode as an extra parameter.    i think
> that this is going to be the only way to support both the static and dynamic
> models.   This will be ugly, but having just finished the wide int patch it is
> natural to say "how bad could it be?"   some ports will want to support this
> and some will not.

My starting point is to presume that any port with hardware floating-point 
exceptions and rounding modes should support this.  But since ports would 
probably need to change anyway to ensure operations do raise the right 
exceptions, and to ensure that the machine-independent compiler can tell 
which registers referred to in inline asm are part of the floating-point 
exceptions / rounding modes state, maybe it wouldn't be so bad if they 
also need to change their instruction descriptions to describe the 
involvement of exceptions and rounding modes explicitly.  (You do need to 
handle the case of exceptions and rounding modes with software floating 
point, i.e. libcalls implicitly using them; this applies to powerpc-linux 
soft float at least.)

Of course many target architecture ports are for architectures without 
hardware floating point, and without any exception or rounding mode 
support, and these issues don't arise for them.

(When I say above certain things are the main difficulty I mean they are 
the only things with real design issues that I see.  Lots of other issues 
arise such as:

(a) writing thorough testcases for individual operations working properly 
with exceptions and rounding modes in various contexts (I could probably 
do that at least for basic arithmetic in a week or two; properly it should 
be done for every IEEE operation for which GCC allows a built-in function 
to be expanded inline);

(b) going through transformations to review whether they are correct for 
exceptions and rounding modes (a good starting point would be all 
references to e.g. HONOR_SIGN_DEPENDENT_ROUNDING, HONOR_NANS and 
flag_trapping_math, many of which are likely not checking quite the right 
condition, although transformations with no such checks are harder to 
find);

(c) avoiding spurious exceptions from libgcc functions e.g. converting 
floating-point to DImode;

(d) ensuring the right exceptions from converting floating-point to 
bit-fields;

(e) converting the standard pragmas to appropriate IR describing what 
transformations are permitted on what code;

(f) if you do Annex G as well, the ABI for _Imaginary argument passing.

When you get into static rounding modes, as described in TS 18661-1, there 
are a few more issues; e.g.:

(g) supporting both architectures that can encode rounding modes in 
instructions, and those where the rounding mode needs swapping at runtime;

(h) allowing library headers to define macros for standard library 
functions that cause them to use the constant rounding mode;

(i) ensuring that <float.h> macros have the correct value in all constant 
rounding modes, which is easy if they use hex floats, but if you allow the 
combination of C90 mode with constant rounding modes then you need long 
decimal expansions of those macros, so maybe that combination should be 
disallowed.

Those are examples of miscellaneous issues that I generally expect could 
be addressed by lots of incremental patches without tricky overall design 
issues.  More would probably come up in a full analysis / design process 
of how to do a high-quality implementation of C99/C11 Annex F/G and TS 
18661-1.)

-- 
Joseph S. Myers
joseph@codesourcery.com