Re: Adding Rounding Mode to Operations Opcodes in Gimple and RTL

[Michael Zolotukhin <michael dot v dot zolotukhin at gmail dot com>]

> 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 <joseph@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
> joseph@codesourcery.com



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.