This is the mail archive of the 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/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.

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 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.
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.


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