All fuchsia targets will now use the relative-vtables ABI by default. Also remove -fexperimental-relative-c++-abi-vtables from test RUNs targeting fuchsia.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3296 | Could we instead enable it inside FuchsiaCXXABI? |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3296 | So we can't necessarily turn this on in just FuchsiaCXXABI/CodeGen because many of the vtable offsets and components are constructed in the AST stage which is later consumed by codegen and the CXXABI classes to make the vtables. More specifically, it's the ItaniumVTableContext created in ASTContext::getVTableContext() in charge of calculating these offsets. I put it here because controlling the flag seems like the easiest way to set a default value given the target, and it's available either during or before the AST stage. |
Change the tablegen definition of -f[no-]experimental-relative-c++-abi-vtables from a BoolFOption to two separate flags so we can control the default value of the RelativeCXXABIVTables LangOption more explicitly. This is needed so we can set the default value of this option depending on the target.
Ready for reviews. Let me know if I should add other reviewers for the flag/option processing. This shouldn't impact how the experimental flag is used. It's just processing it that's different.
clang/include/clang/Basic/TargetCXXABI.h | ||
---|---|---|
69 | I think that supports here is a bit misleading, I'd expect the return value to signal whether relative vtables C++ ABI is supported or not but not control the default. Maybe usesRelativeVTables? |
I think that supports here is a bit misleading, I'd expect the return value to signal whether relative vtables C++ ABI is supported or not but not control the default. Maybe usesRelativeVTables?