[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