- User Since
- Nov 14 2016, 12:37 PM (200 w, 6 d)
Thu, Sep 17
LGTM - thanks
Wed, Sep 16
I pulled out the isStrictFP boolean from EvalInfo and used the FPOptions when visiting floating point BinaryOperator, CastExpr and builtin CallExpr. I created the diagnostic note explaining why constant evaluation failed. Not certain about the language rules C vs C++.
Mon, Sep 14
This update uses context information from Expr->getFPFeaturesInEffect() to disable fp constant folding in ExprConstant.cpp
I've been given a vague assignment, something along the lines "investigate floating point constant folding and make sure that the semantics are correct. " In the Intel ICL compiler, there were some circumstances of the semantics not being correct. I saw Richard's comments in this review, and Intel also needs FENV_ACCESS implemented so I thought I'd start here. I'm not a floating point expert, but of course some of my colleagues at Intel are! I am pretty slow but it's my area of focus.
But sometimes, if the floating point semantics are set to 'strict', even tho' folding has occurred successfully in ExprConstant.cpp, when i look at emit-llvm, there is arithmetic emitted for the floating point expression;
I used a bit different approach, may be it could be useful for you too. An initializer for global variable must be a constant, so things like const xxx = 1.0 + 2.0 are evaluated. No llvm arithmetic occurs in the resulting ll file. Using pragma STDC FENV_ROUND floating point environment may be set to non-default state, which constant evaluator must use.
When I implemented clang #pragma float_control, I noticed that initialization expressions in classes were not subject to the pragma's that are active in the source file. Those expressions are pulled out and processed differently than the function bodies. I'll upload later today a patch that uses Expr->getFPFeaturesInEffect() to inhibit constant folding in ExprConstant.cpp.
This is definitely a good idea.
I'll look into it, thank you
Fri, Sep 11
Hello, I rebased this and made a few changes here, https://reviews.llvm.org/D87528 ; I added a question about floating point constant folding in that review, I'm going to duplicate it here,
Wed, Sep 2
Jun 27 2020
Jun 26 2020
with updates from @yaxunl , i'm planning to push this
Jun 24 2020
I decided that I shouldn't make float options that define a macro, like -ffast-math, as BENIGN_LANGOPT, I made ffp-contract= , fp-exception-behavior and rounding-mode BENIGN, I modified the pch test case to test that the benign command line floating options on the pch-create don't affect compilations that use the pch file.
Jun 23 2020
I need to make another revision that makes a couple more of the fp options, like ffp-contract, "benign" and add a test case that demonstrates fp options don't carry over from pch-create to pch-use
The difference between this patch and the earlier one today is that I modified the new test case
I responded to review from @riccibruno and @rjmccall : I put the dump() routines into the .cpp file and changed them to use the x-macros. I moved CXXOperatorCall.FPOptionsOverride from the Expr bits into the OperatorCall itself. I added the operator call test case suggested by John. I must be mistaken about the bug, the operator call addition does account for the FPFeatures in both the unmodified compiler and the patched compiler.
Jun 22 2020
@rjmccall I added some inline questions and comments for you. Thanks a lot for your review.
This revision rewrites FPOptionsOverride like @rjmccall suggests. There are a couple problems, i'll add inline comments in the trouble areas
Jun 16 2020
This version passes all the lit tests, i believe it's functional tho' maybe not elegant.
I still need to add a test case that PCH behaves as desired, and that the floating point command line options from PCH create do not clobber command line options from compilations that use a pch
Jun 15 2020
@rjmccall You suggested that the FPFeatures could be delta instead of absolute settings, I think this is approximately what you mean. This is a rough patch employing that idea, would welcome your early comments. There are 2 clang tests that are failing with this patch, I need to dig into those.
Jun 1 2020
May 20 2020
Thanks for cleaning this up!
May 15 2020
This is the same as the previous patch, except I removed the fix for pragma push-pop that John said should be committed separately
May 14 2020
reply about the incorrect setting of 'fast' during OpenCL compilation with option -cl-fast-relaxed-math
May 13 2020
added some inline explanation
May 12 2020
May 11 2020
@rjmccall Uncertain how to proceed, can you recommend? If I recall correctly, I added the lines in CompilerOptions because there were many failing lit tests, i could have fixed the lit fails by adding the lang options to the lit tests. (of course that change could have other repercussions)
May 9 2020
I corrected the assertion error by propagating usesFPIntrin flag from the template function to the template instantiation and added a test case. Ready for review.
May 8 2020
No this patch isn't ready yet. i see an assertion if try to instantiate a template function when the template has enabled floating point settings
I got a report that this patch was causing a problem with Windows <numeric> header because #pragma float_control should be supported in namespace context. I've posted a patch for review here https://reviews.llvm.org/D79631
May 6 2020
The ISO C proposal is here http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2407.pdf but the details are in the IEEE standards documents.
BTW there is a proposal http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2421.pdf at the ISO C meeting to support some new floating point pragmas including
#pragma STDC FENV_ALLOW_ASSOCIATIVE_LAW on-off-switch
The committee wants to see an implementation(s) to ensure that it's viable.
May 5 2020
Here it is again with the on/off spelling
I checked with FPGA folks and confirm what @scanon says is correct, the reassoc fast math flag enables reassociation across multiple statements, so i changed the syntax to use 'fast' and 'off', and changed the documentation
May 4 2020
A reply to @scanon
Responded to @rjmccall 's review.
May 1 2020
Apr 30 2020
I changed a comment to add a period, rebased, and used clang-format
Apr 29 2020
I dropped FPOptions from CallExpr -- if it's needed I will add it using TrailingStorage in a separate patch; I responded to @erichkeane 's code review
Apr 27 2020
A couple replies to @erichkeane