[llvm] [WPD]: Enable speculative devirtualizatoin. (PR #159048)
Teresa Johnson via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 17 16:31:58 PDT 2025
teresajohnson wrote:
> > > @teresajohnson I think it's better to handle the object visibility in this patch too ? Direct devirtualization for hidden objects and speculative for non-hidden ones ?
> >
> >
> > I could go either way. It is fine if you want to add that here, but I'm also fine with doing it as a follow up which might make the patches a bit more compact (unless you think adding the support will cause many changes to what is added by this PR).
>
> I think the change of handling the visibility will just pass the object visibility to 'applySingleImplDevirt' to check if we apply speculative/direct devirtualization. So the changes will include changing the function prototype, and passing the parameter. something like:
>
> ```
> void DevirtModule::applySingleImplDevirt(VTableSlotInfo &SlotInfo,
> Constant *TheFn, bool &IsExported,
> std::optional<GlobalObject::VCallVisibility> ObjVisibility) {
> ..
> if (DevirtCheckMode == WPDCheckMode::Fallback || (speculativeDevirt && ObjVisibility != hidden)
> ... apply speculative devirt.
> else // it will do the direct devirt.
> }
>
> bool DevirtModule::trySingleImplDevirt(
> ModuleSummaryIndex *ExportSummary,
> MutableArrayRef<VirtualCallTarget> TargetsForSlot, VTableSlotInfo &SlotInfo,
> WholeProgramDevirtResolution *Res) {
> ...
> applySingleImplDevirt(SlotInfo, TheFn, IsExported, TargetsForSlot.TM.Bits->GV->getVCallVisibility());
> }
> ```
I think you are correct that this would be what is needed. Again I could go either way. It might be nice to keep this PR somewhat smaller and add that along with some tests for it as a follow on. As is this PR is largely lgtm except I think for one older comment suggestion that wasn't addressed and one new change I'm about to suggest.
https://github.com/llvm/llvm-project/pull/159048
More information about the llvm-commits
mailing list