================
@@ -240,3 +240,49 @@ LLVM_DUMP_METHOD void FPOptionsOverride::dump() {
#include "clang/Basic/FPOptions.def"
llvm::errs() << "\n";
}
+
+AtomicOptionsOverride
+AtomicOptions::getChangesSlow(const AtomicOptions &Base) const {
+ AtomicOptions::storage_type OverrideMask = 0;
+#define OPTION(NAME, TYPE, WIDTH, PREVIOUS)
\
+ if (get##NAME() != Base.get##NAME())
\
+ OverrideMask |= NAME##Mask;
+#include "clang/Basic/AtomicOptions.def"
+ return AtomicOptionsOverride(*this, OverrideMask);
+}
+
+LLVM_DUMP_METHOD void AtomicOptions::dump() {
+#define OPTION(NAME, TYPE, WIDTH, PREVIOUS)
\
+ llvm::errs() << "\n " #NAME " " << get##NAME();
+#include "clang/Basic/AtomicOptions.def"
+ llvm::errs() << "\n";
+}
+
+LLVM_DUMP_METHOD void AtomicOptionsOverride::dump() {
+#define OPTION(NAME, TYPE, WIDTH, PREVIOUS)
\
+ if (has##NAME##Override())
\
+ llvm::errs() << "\n " #NAME " Override is " << get##NAME##Override();
+#include "clang/Basic/AtomicOptions.def"
+ llvm::errs() << "\n";
+}
+
+AtomicOptionsOverride::AtomicOptionsOverride(const LangOptions &LO) {
+ for (const auto &Setting : LO.AtomicOptionsAsWritten) {
+ SmallVector<StringRef, 2> KeyValue;
+ StringRef(Setting).split(KeyValue, ":");
+ // Assuming option string has been checked elsewhere and is valid.
+ assert(KeyValue.size() == 2 && "Invalid atomic option format");
+ StringRef Key = KeyValue[0];
+ StringRef Val = KeyValue[1];
+ bool IsEnabled = (Val == "on");
+
+ if (Key == "no_fine_grained_memory")
+ setNoFineGrainedMemoryOverride(IsEnabled);
+ else if (Key == "no_remote_memory")
+ setNoRemoteMemoryOverride(IsEnabled);
+ else if (Key == "ignore_denormal_mode")
+ setIgnoreDenormalModeOverride(IsEnabled);
----------------
Artem-B wrote:
Would it make sense to generalize those separate calls into a single
`setOverride(enum OverrideKind, value)`?
They all are handled about the same way, and having just one API call to handle
them may simplify processing a bit as the key/value pairs will match directly
to the arguments. E.g. it would allow figuring out the key and the value
separately. Right now the attribute parsing code seems to process full
cartesian product of key/value combinations. We only have few of the possible
keys, so it's not a showstopper, but I wonder if we can do better.
https://github.com/llvm/llvm-project/pull/114841
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
