Skip to content

Enable WPD without lto #141777

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Enable WPD without lto #141777

wants to merge 1 commit into from

Conversation

hassnaaHamdi
Copy link
Member

@hassnaaHamdi hassnaaHamdi commented May 28, 2025

I have created this draft to collect some opinions about the idea of allowing devirtualization without the need to lto or forcing any kind of visibility.

I think applying speculative devirtualization could not need lto because it will be safe to be done to each single module without caring if there are other modules/lib that may do inheritance or caring about the visibility.

So, I suggest that if lto is enabled, the original logic will apply. If nolto, the speculative devirtualizaation will apply (maybe without the other features like virtual constant prop).

The idea could be done by either refactoring the current WPD pass and make it able to run with/out lto, or creating a new pass.

-Side note- there are some code snippets that are commented, I just mean that they maybe not needed for the case of nolto, but generally if the idea got accepted, that code will be refactored to work only with lto.

This work could be useful for cases that don't need lto.
I think there are some open issues related to devirtualization, and they don't need lto, this solution could be useful for them.
Also I tested it on SPEC, highest performance was around 2-3% and worst regression was not more than 1.5%.

Could you put your feedback please ?

@teresajohnson
Copy link
Contributor

This is an interesting idea, thanks for the performance numbers. It could also be useful for LTO without whole program visibility enabled, where most of the vtables and type tests will end up with public visibility making them ineligible for WPD. But I suspect it may not be profitable when there is any type of PGO, which will cause speculative devirtualization to be applied for profiled indirect calls via ICP. Can you share the detailed SPEC performance results?

@hassnaaHamdi
Copy link
Member Author

This is an interesting idea, thanks for the performance numbers. It could also be useful for LTO without whole program visibility enabled, where most of the vtables and type tests will end up with public visibility making them ineligible for WPD. But I suspect it may not be profitable when there is any type of PGO, which will cause speculative devirtualization to be applied for profiled indirect calls via ICP. Can you share the detailed SPEC performance results?

Hi @teresajohnson Thanks so much for looking at it.
Here are screenshots for the change rate results for SPECv6.
specv6_int
specv6_fp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants