This is the mail archive of the
mailing list for the GCC project.
Re: patch to fix rtl documentation for new floating point comparisons
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 17 Feb 2015 19:17:07 -0500
- Subject: Re: patch to fix rtl documentation for new floating point comparisons
- Authentication-results: sourceware.org; auth=none
- References: <54D9063D dot 1000102 at naturalbridge dot com> <alpine dot DEB dot 2 dot 10 dot 1502092223140 dot 32543 at digraph dot polyomino dot org dot uk> <54D95C03 dot 1090904 at naturalbridge dot com> <alpine dot DEB dot 2 dot 10 dot 1502102141060 dot 31125 at digraph dot polyomino dot org dot uk> <54DFAF8C dot 6000906 at gnu dot org> <54E0C471 dot 1090704 at naturalbridge dot com> <54E312E4 dot 707 at foss dot arm dot com> <alpine dot DEB dot 2 dot 10 dot 1502171155440 dot 26958 at digraph dot polyomino dot org dot uk>
On 02/17/2015 07:05 AM, Joseph Myers wrote:
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.
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
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).
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.
I suspect there are two ways we could deal with that: add new comparison
RTL codes to distinguish the cases; or use something like the RTL /v bit
on a comparison to indicate that it should be signalling.
Of the two, the latter would probably be easiest to implement in a
backwards compatible manner (backends not understanding /v would
continue to use their existing code paths), but it would still take a
fair amount of rejigging in the mid end to fully preserve the signalling
nature of comparisons: there are many places where just RTX_CODE is
available and a new pattern is generated from that. The first method
would require all back-ends to be updated pretty much simultaneously to
handle the new RTL codes.
I don't know the optimal way of representing these variants in GENERIC,
GIMPLE and RTL (the existing representation can cover everything, and is
unambiguous apart from LTGT, but may not be optimal).
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.