This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch to fix rtl documentation for new floating point comparisons
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, Paolo Bonzini <bonzini at gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 18 Feb 2015 15:23:27 +0000
- 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> <54E3DA03 dot 5010901 at naturalbridge dot com> <alpine dot DEB dot 2 dot 10 dot 1502180029110 dot 26150 at digraph dot polyomino dot org dot uk> <C0E9884B-396F-4DC7-B7FE-973FFD72FF50 at naturalbridge dot com> <alpine dot DEB dot 2 dot 10 dot 1502180958160 dot 8477 at digraph dot polyomino dot org dot uk> <8B0E394D-281E-448A-8962-178AF0727C2C at naturalbridge dot com>
On Wed, 18 Feb 2015, Kenneth Zadeck wrote:
> > I think the norm is dynamic, because that's what was in IEEE 754-1985,
> > with static rounding added more recently on some processors, because of
> > IEEE 754-2008. (There are other variants - IA64 having multiple dynamic
> > rounding mode registers and allowing instructions to specify which one the
> > rounding mode is taken from.)
> the first ieee standard only allowed the dynamic model. the second
> allows the static model. while dynamic is more common, there are/were
> architectures that are fully static. i believe that the first sparks
> were fully static and this was why the standard changed. ( i could be
> completely wrong on which arch was the first fully static). the private
> port that i am working on is currently fully static, but i am trying to
> change that. code generation of a dynamic program on a fully static
> machine is gruesome.
>
> my point here is that there are fully static machines so do not do
> anything that precludes this.
The C99 standard was hardly designed for such systems, given the
expectation that you can set the rounding mode with fesetround and then
have it affect library functions (those that are fully-defined operations
such as sqrt and fma, that is). It's not that you can't implement it on
such a system (by having the functions contain a switch over the
thread-local variable with the rounding mode, for example, and doing the
same in all user code that enables FENV_ACCESS and might possibly run in
non-default rounding modes), but it's not exactly convenient.
Essentially that would involve the reverse of what TS 18661-1 envisages
when it gives an example of a code sequence with __swapround to implement
constant rounding directions on a machine where the rounding mode is
dynamic only.
(To implement the FENV_ROUND pragma, one might have the front end insert
__builtin_feswapround calls - in which case machines with static rounding
modes would need to reverse that to identify the rounding modes for
particular operations - or one might have it tag the operations and a
later lowering stage insert such calls. That's in addition to affecting
constants and appropriately marked function calls.)
--
Joseph S. Myers
joseph@codesourcery.com