> 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.)
I think we could need some fake variables to reflect current rounding mode/exception flags. These variables then should be updated in the statements you pointed above - i.e. we'll need to build def-use links for them basing on these statements. I was also thinking of another approach: adding some attribute to the call-stmt itself, but that could be difficult to be taken into account in the optimizations, working on def-use and not-iterating over every statement. As far as I understand, CCP is an example of such optimization. Is it correct or am I missing something? > 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. We mostly have problems when there is an 'interaction' between different rounding modes - so a ton of tests that checking correctness of a single operation in a specific rounding mode won't catch it. We could place all such tests in one file/function so that the compiler would transform it as it does now, so we'll catch the fail - but in this case we don't need many tests. So, generally I like the idea of having tests covering all the cases and then fixing them one-by-one, but I didn't catch what these tests would be except the ones from the trackers - it seems useless to have a bunch of tests, each of which contains a single operation and compares the result, even if we have a version of such test for all datatypes and rounding modes. For now I see one general problem (that calls aren't regarded as something that could change result of FP-operations) and it definitely needs a test, but I don't see any need in many tests here. --- Thanks, Michael On 10 January 2013 22:04, Joseph S. Myers <jos...@codesourcery.com> wrote: > 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 > jos...@codesourcery.com -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
