A class with a destructor marked final cannot be derived from, so it should afford the same devirtualization opportunities as marking the entire class final.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
That appears sort of tangential to me. To clarify, this PR is not (necessarily) about devirtualizing destructors themselves, but rather devirtualizing OTHER member function calls for classes whose destructor is marked final, since that is sort of morally equivalent to marking the entire class final.
This seems subtle, but I believe it is correct.
I wonder whether we should provide a warning for a non-final class has a final destructor, since moving the final from the destructor to the class seems like a more obvious way to present the code (and will likely lead to better code generation in compilers that haven't realized they can do this).
clang/lib/AST/DeclCXX.cpp | ||
---|---|---|
2071 ↗ | (On Diff #216657) | This comment doesn't make much sense (pre-existing, but since you're changing it anyway): classes can't be "overridden", they can only be derived from. |
@rsmith I agree having a final destructor in a non-final class smells weird. I'd be interested in working on adding a warning like that, if it sounds like a useful thing.
For now, I need help committing this, if anyone would be so kind!
Nice.
Richard, do you think there may be some missed devirtualization optimizations that would trigger if the class, rather than the destructor, is declared final in Clang? It seems this patch would take care of common call devirtualizations.