[PATCH] D81869: Modify FPFeatures to use delta not absolute settings to solve PCH compatibility problems
Melanie Blower via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Jun 22 14:31:43 PDT 2020
mibintc marked 6 inline comments as done.
mibintc added a subscriber: yaxunl.
mibintc added a comment.
@rjmccall I added some inline questions and comments for you. Thanks a lot for your review.
================
Comment at: clang/include/clang/AST/ExprCXX.h:172
+ FPOptionsOverride getFPFeatures() const {
+ return FPOptionsOverride(CXXOperatorCallExprBits.FPFeatures);
}
----------------
It seems that this field is basically not used, if I eliminate all these member functions then the AST reader-writer fails but the information isn't being used in Sema or Codegen. I guess there's a bug somewhere if this information is actually needed when creating Float comparison codegen. Also,, from reading the comments in this file it sems that it is needed only when "rewrite == operator into OperatorCall as required by CXX20", the comments also say that the OperatorCall rewrite could equally have occurred as a rewrite into a BinaryOperator. If we choose to rewrite the == as BinaryOperator then it wouldn't be necessary to use TrailingStorage to hold FPOptionsOverride. The previously proposed revision didn't adding TrailingStorage on CXXOperatorCall. When I was working on a different patch I did study how to add TrailingStorage to a Call and I didn't know how I could accomplish that.
================
Comment at: clang/include/clang/AST/Stmt.h:620
+ //unsigned FPFeatures : 21;
+ unsigned FPFeatures : 32;
};
----------------
This is a temporary change, I know you don't want me to change the assert to allow a wider size than 8. So if this information is really needed (as I mentioned above it's not being used in Sema or Codegen) then alternatives are
1. rewrite the == comparison using BinaryOperator
2. put the FPFeatures Override into TrailingStorage (i think i will need implementation guidance if this is the path to go)
================
Comment at: clang/include/clang/AST/Stmt.h:1121
Stmt(StmtClass SC) {
- static_assert(sizeof(*this) <= 8,
+ static_assert(sizeof(*this) <= 16,
"changing bitfields changed sizeof(Stmt)");
----------------
this is a temporary change
================
Comment at: clang/include/clang/Basic/LangOptions.def:192
COMPATIBLE_LANGOPT(Deprecated , 1, 0, "__DEPRECATED predefined macro")
-COMPATIBLE_LANGOPT(FastMath , 1, 0, "fast FP math optimizations, and __FAST_MATH__ predefined macro")
-COMPATIBLE_LANGOPT(FiniteMathOnly , 1, 0, "__FINITE_MATH_ONLY__ predefined macro")
-COMPATIBLE_LANGOPT(UnsafeFPMath , 1, 0, "Unsafe Floating Point Math")
-COMPATIBLE_LANGOPT(AllowFPReassoc , 1, 0, "Permit Floating Point reassociation")
-COMPATIBLE_LANGOPT(NoHonorNaNs , 1, 0, "Permit Floating Point optimization without regard to NaN")
-COMPATIBLE_LANGOPT(NoHonorInfs , 1, 0, "Permit Floating Point optimization without regard to infinities")
-COMPATIBLE_LANGOPT(NoSignedZero , 1, 0, "Permit Floating Point optimization without regard to signed zeros")
-COMPATIBLE_LANGOPT(AllowRecip , 1, 0, "Permit Floating Point reciprocal")
-COMPATIBLE_LANGOPT(ApproxFunc , 1, 0, "Permit Floating Point approximation")
+BENIGN_LANGOPT(FastMath , 1, 0, "fast FP math optimizations, and __FAST_MATH__ predefined macro")
+BENIGN_LANGOPT(FiniteMathOnly , 1, 0, "__FINITE_MATH_ONLY__ predefined macro")
----------------
Here's another problem, I added the test case from bug 46166 @yaxunl but that test case reports incompatibility because the pch is compiled with different settings than where it is used. I thought maybe based on the name, BENIGN_LANGOPT would allow different option values to not get the pch complaint but that didn't work, clang still complained about the different option values. Is there some existing way to get around the option complaint or do I need to invent a new field in the LANGOPT e.g. a boolean that says "Allow opton values to differ between pch-create and pch-use". I haven't deeply studied this to see if I'm missing something. I wanted to send this out to get comments on my other questions
================
Comment at: clang/include/clang/Basic/LangOptions.h:455
+ llvm::errs() << "\n RoundingMode " <<
+ static_cast<unsigned>(getRoundingMode());
+ llvm::errs() << "\n FPExceptionMode " << getFPExceptionMode();
----------------
Using #define OPTION trick would be preferrable except there is a compilation failure because something funny about RoundingMode--need the cast. doubtless there is fix for that
================
Comment at: clang/lib/Parse/ParsePragma.cpp:657
- Actions.ActOnPragmaFPContract(FPC);
- ConsumeAnnotationToken();
+ SourceLocation PragmaLoc = ConsumeAnnotationToken();
+ Actions.ActOnPragmaFPContract(PragmaLoc, FPC);
----------------
Note: This patch is putting all the pragma's that modify floating point state into the FpPragmaStack, using the "Set" call to set the top value of the FP pragma stack. Of course the pragma's that affect the "fp contract" and "reassociate" etc. don't support stacking settings e.g. with PUSH and POP.
================
Comment at: clang/test/SemaOpenCL/fp-options.cl:1
+// RUN: %clang_cc1 %s -finclude-default-header -triple spir-unknown-unknown -emit-pch -o %t.pch
+// RUN: %clang_cc1 %s -cl-no-signed-zeros -triple spir-unknown-unknown -include-pch %t.pch -fsyntax-only -verify
----------------
Here's the new test case from @yaxunl that I mentioned above. This test is failing. Besides that, check-all is passing all the lit tests
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D81869/new/
https://reviews.llvm.org/D81869
More information about the cfe-commits
mailing list