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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
