Adding Rounding Mode to Operations Opcodes in Gimple and RTL

[Joseph S. Myers]

On Thu, 10 Jan 2013, Michael Zolotukhin wrote:

> Thanks for the responses!
> I'll think about your warnings and decide whether I could afford such
> effort or not, but anyway, I wanted to start from GCC, not glibc.
> Am I getting it right, that before any other works we need to fix PR
> 34678 (that's correct number, thanks Mark!), making all passes take
> into account that calls could change rounding-modes/raise exceptions,
> i.e. make all calls optimization barriers? At least, when no
> 'aggressive' options were passed to the compiler.

There are various overlapping bugs in Bugzilla for issues where 
-frounding-math -ftrapping-math fail to implement all of FENV_ACCESS (I 
think of exceptions and rounding modes support together, since they have 
many of the same issues and both are covered by FENV_ACCESS, although it 
may be possible to fix only a subset of the issues, e.g. just rounding 
modes without exceptions).  To what extent the issues really duplicate 
each other isn't entirely clear; I'd advise looking at all the testcases 
in all relevant PRs (both open (576 20785 27682 29186 30568 34678), and 
others marked as duplicates of open ones), even if you then end up only 
working on a subset of the problems.

Yes, doing much related to rounding modes really requires making the 
compiler respect them properly for -frounding-math.  That's not quite 
calls being optimization barriers in general, just for floating point.

* General calls may set, clear or test exceptions, or manipulate the 
rounding mode (as may asms, depending on their inputs / outputs / 
clobbers).

* Floating-point operations have the rounding mode as input.  They may set 
(but not clear or test) floating-point exception flags.

* Thus in general floating-point operations may not be moved across most 
calls (or relevant asms), or values from one side of a call reused for the 
same operation with the same inputs appearing on the other side of the 
call.

* Statements such as "(void) (a * b);" can't be eliminated because they 
may raise exceptions.  (That's purely about exceptions, not rounding 
modes.)

Personally I'd think a natural starting point on the compiler side would 
be to write a reasonably thorough and systematic testsuite for such 
issues.  That would cover all operations, for all floating-point types 
(including ones such as __float128 and __float80), and conversions between 
all pairs of floating-point types and either way between each 
floating-point type and each integer type (including __int128 / unsigned 
__int128), with operands being any of (constants, non-volatile variables 
initialized with constants, volatile variables, vectors) and results being 
(discarded, stored in non-volatile variables, stored in volatile 
variables), in all the rounding modes, testing both results and exceptions 
and confirming proper results when an operation is repeated after changes 
of rounding mode or clearing exceptions.

The idea would be that the tests would all be expected to pass once the 
problems in this area have been fixed.  They'd be run over different 
optimization options, like the existing torture tests, as well as over 
variants such as -mfpmath=387 / -mfpmath=sse where applicable.  Right now, 
some would probably pass (especially with "volatile" and at -O0), others 
fail.  The difficulty might be in setting up good XFAIL state for such 
tests to reflect what does / does not work before the compiler has been 
cleaned up in this area - that state is probably pretty complicated right 
now.  I suppose a testsuite could be kept external until the tests all 
pass on some targets, but it would seem better to be able to have the 
tests in-tree while work is done incrementally on making the compiler 
better in this area, so that the improvements in a patch can readily be 
seen as "N XFAILs removed".

(More could certainly be done on the glibc testsuite side to cover 
exceptions / rounding modes issues better there as well, although there's 
more existing coverage of such issues now than there is in the GCC 
testsuite.)

> That work seems to be quite big and it really can cause huge tests

Yes, there is certainly a huge amount that can be improved regarding 
floating-point issues in the GNU toolchain in general (GCC and glibc), and 
room for plenty of people to work on different improvements; I'd certainly 
be glad to see any improvements on such floating-point infrastructure 
(which historically has received less development attention than, for 
example, optimization or porting).

> fallout, but when it's done adding new subcodes for operations with
> rounding shouldn't cause any new fails (as we won't change behavior of
> 'default' operations).

Once you're supporting operations with constant rounding, for it to be 
useful you'll need a way for source code to generate them - whether 
detecting fesetround pairs as you previously suggested, or the constant 
rounding mode C bindings in the draft first part of the TS for C bindings 
to IEEE 754-2008.  So even if in theory you don't change anything about 
how existing code is handled, I expect the changes would still involve 
some risk of fallout.

-- 
Joseph S. Myers
joseph@codesourcery.com