[PATCH] Defining a new API for debug options that doesn't rely on static global cl::opts.
Chandler Carruth
chandlerc at gmail.com
Fri Oct 10 02:32:25 PDT 2014
Again, the API in the pass seems pretty good. More comments on the implementation.
================
Comment at: include/llvm/IR/LLVMContext.h:167-170
@@ -165,1 +166,6 @@
+ template <typename ValT, typename Base, ValT(Base::*Mem)>
+ ValT getOption() const {
+ return OptionRegistry::instance().template get<ValT, Base, Mem>();
+ }
+
----------------
This needs some documentation. =]
================
Comment at: include/llvm/PassSupport.h:87
@@ +86,3 @@
+ INITIALIZE_PASS_BEGIN(passName, arg, name, cfg, analysis) \
+ passName::RegisterOptions(); \
+ INITIALIZE_PASS_END(passName, arg, name, cfg, analysis)
----------------
We should use the new naming conventions here so we aren't establishing new non-conventional API requirements.
================
Comment at: include/llvm/Support/Options.h:21-22
@@ +20,4 @@
+
+// The option keys are unique based on the base type, value type and member
+// offset of the option's final storage.
+typedef char LLVMOptionKey;
----------------
This comment doesn't really make sense to me. Not sure what its trying to say...
Maybe just: 'Options are keyed off the unique address of a static character, potentially one synthesized based on a particular set of template arguments'?
================
Comment at: include/llvm/Support/Options.h:23
@@ +22,3 @@
+// offset of the option's final storage.
+typedef char LLVMOptionKey;
+
----------------
Not sure giving this type a name really helps.
I would just use a 'void *' as the key type internally, and the class template as the external interface? If you want to make the 'void *' raw key type available for clients, I would typedef 'OptionKey' to 'void *', and name the template for synthesizing a static variable whose address is a suitable 'void *' key for a set of template arguments something like 'OptionKeyFromTemplateArgs'.
================
Comment at: include/llvm/Support/Options.h:31
@@ +30,3 @@
+template <typename ValT, typename Base, ValT(Base::*Mem)>
+LLVMOptionKey OptionKey<ValT, Base, Mem>::ID = 0;
+
----------------
Why initialize it at all?
================
Comment at: include/llvm/Support/Options.h:33-35
@@ +32,5 @@
+
+//===----------------------------------------------------------------------===//
+// OptionRegistry class
+//
+class OptionRegistry {
----------------
Please use modern doxygen syntax here and elsewhere. Also it would be good to give the class a reasonable introductory comment.
================
Comment at: include/llvm/Support/Options.h:38
@@ +37,3 @@
+private:
+ DenseMap<LLVMOptionKey *, cl::Option *> Options;
+
----------------
Should document that this owns the cl::Option objects pointed to but doesn't use std::unique_ptr or delete them but instead intentionally leaks them.
================
Comment at: include/llvm/Support/Options.h:45-46
@@ +44,4 @@
+public:
+ ~OptionRegistry();
+ OptionRegistry() {}
+
----------------
Shouldn't these be private? Only a single global instance of this registry can exist in order to make the ownership semantics of the cl::Option objects reasonable?
http://reviews.llvm.org/D5389
More information about the llvm-commits
mailing list