This field is currently not used by anything, and using a ClassID instance provides better support for more efficient classof.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unit tests: pass. 61895 tests passed, 0 failed and 782 were skipped.
clang-tidy: unknown.
clang-format: pass.
Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Thanks for this, it looks like a good solution to the problems I've seen, although I haven't tested it.
I built a shared library (D73130) and run into the case that my HasParent<FuncOp> trait failed to verify.
(gdb) mlir::Op<mlir::FuncOp, mlir::OpTrait::ZeroOperands, mlir::OpTrait::ZeroResult, mlir::OpTrait::IsIsolatedFromAbove, mlir::OpTrait::Symbol, mlir::OpTrait::FunctionLike, mlir::CallableOpInterface::Trait>::classof (op=0x555555e67550) at /data/vchuravy/mlir/build/usr/include/mlir/IR/OpDefinition.h:987 987 return ClassID::getID<ConcreteType>() == abstractOp->classID; (gdb) p abstractOp->classID $7 = (mlir::ClassID *) 0x7ffff698e020 <mlir::ClassID* mlir::ClassID::getID<mlir::FuncOp>()::id> (gdb) p ClassID::getID<mlir::FuncOp>() $8 = (mlir::ClassID *) 0x7ffff7aee120 <mlir::ClassID* mlir::ClassID::getID<mlir::FuncOp>()::id>
So it seems it still might be the case that pointer can differ. D72584 fixed this by falling back more often to the string comparison.
So it seems it still might be the case that pointer can differ. D72584 fixed this by falling back more often to the string comparison.
You are going to run into a much bigger problem given that this depends on ClassOf, which is a static typeid that is used pervasively across the entire code base. Making that work with shared libraries is likely the most important(difficult?) task item.