-
-
Notifications
You must be signed in to change notification settings - Fork 703
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std.math: change tests for rounding #7109
Conversation
Thanks for your pull request, @WalterBright! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + phobos#7109" |
Option (2) remains a problem even with intrinsics, because if the intrinsic is wrapped in a function call, the optimizer still won't know it happened. |
This problem was exposed by dlang/dmd#10177 which improves CSE computation for DMD, and is blocking it. |
07df96b
to
7d05076
Compare
Option (2) sounds like the best one in the long-term. Obviously you prefer a short-term solution which doesn't block your work, but I'm not sure about the conferences of (3). What concerns me is that a change in dmd's optimizer necessitates a change in user's code and I am not sure I fully understand the consequences. Does it mean that all code that changes the FP rounding mode inside one function body will be broken with the new optimizations? If not, then why this change is necessary, after all it is changing the optimization of unittest code (which doesn't seem actually important, enough so to block other work)? |
It may be broken already. Optimizations that involve constant folding will be done in the compiler with round to nearest, which won't do the same thing at runtime if the rounding mode is set differently. Basically, you're going to have to know what you're doing when manipulating the rounding mode. Fortunately, few people ever do it. |
And as I noted, a compiler intrinsic probably won't be effective anyway. |
The buildkite weka error seems unrelated. |
b4cad31
to
cb9e5fc
Compare
Changing floating point rounding modes, because it happens off to the side, interferes with optimizing. In particular, common subexpressions may not be common if the rounding mode is changed.
Solutions are:
This does option (3).