[clang] Add clang atomic control options and attribute (PR #114841)
Artem Belevich via cfe-commits
cfe-commits at lists.llvm.org
Wed Jan 29 15:29:48 PST 2025
================
@@ -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
More information about the cfe-commits
mailing list