Details
- Reviewers
nicolasvasilache lattner rriddle stellaraccident - Commits
- rG4bb0ad2382a1: Emit strong definition for TypeID storage in Op/Type/Attributes definition
rG660a56956c32: Emit strong definition for TypeID storage in Op/Type/Attributes definition
rGb349d4c5e185: Emit strong definition for TypeID storage in Op/Type/Attributes definition
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td | ||
---|---|---|
24 | FWIW, these namespace cleanups to Affine dialect are "obvious" and can be landed separately | |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
2601 | I'm thrilled to see this. Given this is emitted into a C++ file, you could emit these as true global variables, instead of as lazily initialized things within the function. Does clang optimize the lazily initialized one away when it has no initializer? If clang handles this correctly then your approach is better, but if not, then hand holding it seems best given this is autogenerated code. This would look something like this: os << " static TypeID::Storage <name_mangled>_typeid_instance;\n"; os << "template<>\n"; os << "mlir::TypeID mlir::detail::TypeIDExported::get<" << op.getCppNamespace() << "::" << op.getCppClassName() << ">() {\n"; os << " return TypeID(&<name_mangled>_typeid_instance);\n"; os << "}\n"; |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
2601 | Does it make a difference if the static is "file scoped" or "function scoped" when the type is trivial? (we're only interested in the address, not the value). I was expecting that this only matters if a constructor has to be invoked. Here is the diff between the two cases as I understand it: https://godbolt.org/z/Msf1PT43j |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
2601 | I don't think it makes a big difference. File-level static is marginally nicer should some poor downstream find themselves in the position of needing to filter symbol lists and such. It should probably also be emitted as visibility default. |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
2601 | Looks identical to me! Please keep it as function scoped then. Thanks again! |
mlir/include/mlir/Dialect/Affine/IR/AffineOps.h | ||
---|---|---|
375 | Not really: we can't do the explicit specialization emitted by TableGen otherwise: we have to rely on the "generated files are included at the top level namespace" I think. That said, yes I'll land the affine dialect change in a separate commit, I left them here to show that this change in ODS generation can break client who haven't switched to the new include model (i.e. not fully specified the namespace for their dialect). |
Unrelated change?