[PATCH] D152405: [WIP][clang] Add experimental option to omit the RTTI component from the vtable when -fno-rtti is used
Roland McGrath via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Jun 7 17:14:47 PDT 2023
mcgrathr added a comment.
In D152405#4404616 <https://reviews.llvm.org/D152405#4404616>, @leonardchan wrote:
> Oh this is completely independent from relative vtables. I'll update the wording.
Great. I'd like to see us try some experiments with enabling both together in places like the Fuchsia kernel where we get benefit from relative-vtables today but it's all a single fungible internal ABI domain and there's no problem having a one-off ABI. It's also interesting of course for true embedded contexts, but those tend to be ILP32 where relative-vtables isn't a size savings anyway. In the Fuchsia kernel we should get some size savings from this and it would be nice to see what that is (probably not all that big, but interesting).
Can we extend the test cases to exercise both with and without relative-vtables also enabled?
>> Does any runtime code (libc++abi) ever need to know the vtable layout details when actually making use of RTTI, such that it would need to adapt to this ABI change?
>
> `__dynamic_cast` is the only thing that comes to mind, but since this is gated on `-fno-rtti` where dynamic_cast is disabled, then I think libc++abi doesn't need to worry about this.
Perfect. This makes this a good free-floating option for any context like kernel or embedded where all code (even if libc++/libc++abi are included) are built from scratch using the same switches.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D152405/new/
https://reviews.llvm.org/D152405
More information about the cfe-commits
mailing list