Enable WPD without lto

[hassnaaHamdi]

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]

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]

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.

[hassnaaHamdi]

Hi @teresajohnson
what do you think?
For the case of PGO, I think we may disable it. I think The speculative devirtualization is useful for cases where we don't have enough information.

[teresajohnson]

Hi @teresajohnson what do you think? For the case of PGO, I think we may disable it. I think The speculative devirtualization is useful for cases where we don't have enough information.

Yes I think the spec results are promising. I'd suggest also trying with a large C++ app like Clang itself, compiling a large source file. Feel free to send a full patch for this change, including some lit tests, and guarded appropriately by a flag.

[hassnaaHamdi]

Hi @teresajohnson what do you think? For the case of PGO, I think we may disable it. I think The speculative devirtualization is useful for cases where we don't have enough information.

Yes I think the spec results are promising. I'd suggest also trying with a large C++ app like Clang itself, compiling a large source file. Feel free to send a full patch for this change, including some lit tests, and guarded appropriately by a flag.

Great, thanks so much for the feedback.