This is an archive of the discontinued LLVM Phabricator instance.

[GlobalDCE] Handle relative pointers in VFE (for Swift vtables)
ClosedPublic

Authored by kubamracek on Aug 6 2021, 7:22 AM.

Details

Summary

As part of codesize optimization work for Swift, we'd like to add Virtual Function Elimination to Swift, very similarly to how GlobalDCE supports C++ VFE. This PR adds support for Swift vtables which contai "relative pointers" instead of direct pointer references. These are in the form of:

@symbol = ... {
  i32 trunc (i64 sub (i64 ptrtoint (<type> @target to i64), i64 ptrtoint (... @symbol to i64)) to i32)
}

The PR extends GlobalDCE's way of looking up a vtable offset into a dependency to be able to see through this expression and find the target symbol.

See the added test for an example this.

Diff Detail

Event Timeline

kubamracek created this revision.Aug 6 2021, 7:22 AM
kubamracek requested review of this revision.Aug 6 2021, 7:22 AM
kubamracek added a reviewer: pcc.
fhahn added inline comments.Aug 24 2021, 11:48 AM
llvm/lib/Analysis/TypeMetadataUtils.cpp
158

I think it would be good at least to have the layout documented somewhere. Not sure where the right place would be, but I think we should have at least a comment here, explaining what the expected valid layout is.

@pcc, @tejohnson any ideas?

168

The sub case here in particular needs some explanation I think. Is there anything we can verify about the layout? E.g. here the second operand always needs to be the vtable global, right?

llvm/lib/Transforms/IPO/GlobalDCE.cpp
138

Could you also explain *why* those dependencies can be safely ignored?

141

Does this extra code also apply to the non-swift case? If so, could you add a non-swift related test case?

Also, could this part split off from the extension to getPointerAtOffset or are both needed for any transformation to happen in the swift case?

llvm/test/Transforms/GlobalDCE/virtual-functions-swift.ll
1

Can this simplify be removed? It is run again below and the output is piped to FileCheck.

kubamracek retitled this revision from [GlobalDCE] Prepare VFE for Swift vtables (handle relative pointers and non-nfunc entries) to [GlobalDCE] Handle relative pointers in VFE (for Swift vtables).
kubamracek edited the summary of this revision. (Show Details)

@fhahn added explaining comment that shows the form of the relative pointer expression, added extra structure checking for "sub", removed the "allow non-vfunc entries in the vtable" part.

kubamracek added inline comments.Aug 25 2021, 4:03 PM
llvm/lib/Transforms/IPO/GlobalDCE.cpp
138

This is now removed from the patch, but for completeness, there was a typo in the comment that suggested that the change was ignoring more dependencies compared to the existing code -- that was a typo, the change was actually "keeping" some dependencies as "regular" deps, specifically if they don't have an entry in the !type metadata, therefore they are not a vfunc.

https://reviews.llvm.org/D108741 [GlobalDCE] Handle non-vfunc entries in vtables during VFE (for Swift vtables)

fhahn added inline comments.Aug 26 2021, 2:14 AM
llvm/lib/Analysis/TypeMetadataUtils.cpp
129

I think this comment would be helpful at the declaration in the header, so it is included in the auto-generated documentation. So it might be good to move this to the header and maybe have an inline code comment mark where the swift-specific handling starts?

177

Could you also add a test case for that?

kubamracek added inline comments.Aug 26 2021, 10:20 AM
llvm/lib/Analysis/TypeMetadataUtils.cpp
177

That's tough without https://reviews.llvm.org/D108741, because returning "not found" from this function is currently going to make GlobalDCE be *more aggressive* and remove that slot from the vtable. Writing a test for this behavior is... "weird" because that behavior sounds like a bug (to be fixed with https://reviews.llvm.org/D108741).

fhahn accepted this revision.Aug 27 2021, 12:03 PM

LGTM, thanks for splitting this off.

Please wait a couple of days with committing, in case there are additional comments/concerns.

llvm/lib/Analysis/TypeMetadataUtils.cpp
177

It would still provide coverage for that code path.

This revision is now accepted and ready to land.Aug 27 2021, 12:03 PM
kubamracek added inline comments.
llvm/lib/Analysis/TypeMetadataUtils.cpp
177

Good point. I have added a test for that, and I'll fix the test with the subsequent change to test for the expected behavior.

This revision was landed with ongoing or failed builds.Aug 31 2021, 7:07 AM
This revision was automatically updated to reflect the committed changes.