In constructor type homing mode sometimes complete debug info for constexpr
types was missing, because there was not a constructor emitted. This change
makes constructor type homing ignore constexpr types.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
2264–2266 | I'm not sure isLiteral is quite the right check. I think there are some ways to:
I came up with this example: struct ConstexprCtor { constexpr ConstexprCtor(int a, int b) : a(a + 1), b(b + 1) {} ~ConstexprCtor(); int a, b; }; [[clang::no_destroy]] ConstexprCtor static_gv{1, 2}; I tried to find other ways to construct a class in a constexpr context without running the destructor, but wasn't able to. It would also be interesting to know if StringRef and ArrayRef are literal or not. Those seem like types that we would want to apply this optimization to, and they have constexpr constructors. Maybe we can find a way to apply the optimization by figuring out if a constexpr constructor has been evaluated. You could look at who calls Sema::MarkFunctionReferenced and see if there are any callbacks into the ASTConsumer around there. |
clang/lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
2264–2266 | Was (well did, and then realized you'd covered it) going to say the same thing about "is literal type" probably being too narrow here. Testing for the presence of a non-copy/move ctor constexpr ctor I think would be the right test. I'd say it'd be best to fix this broadly first, then in a separate patch/work try to find a way to get some types with constexpr ctors back in - as I think that's going to be extra tricky with optimizations, linkages, etc. Maybe not - but I think there's enough to discuss there that we shouldn't tie that discussion together with this correctness issue. |
clang/lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
2264–2266 | Sounds good! And yeah, I sort of started looking into how to not ignore all constexpr ctor types, makes sense to put it in a separate patch. |
I'm not sure isLiteral is quite the right check. I think there are some ways to:
I came up with this example:
I tried to find other ways to construct a class in a constexpr context without running the destructor, but wasn't able to.
It would also be interesting to know if StringRef and ArrayRef are literal or not. Those seem like types that we would want to apply this optimization to, and they have constexpr constructors. Maybe we can find a way to apply the optimization by figuring out if a constexpr constructor has been evaluated. You could look at who calls Sema::MarkFunctionReferenced and see if there are any callbacks into the ASTConsumer around there.