[PATCH] D108741: [IR][GlobalDCE] Add ability to mark vtable methods as eligible for VFE and avoid eliminating non-eligible vfunc in VFE in GlobalDCE

[John McCall via Phabricator via llvm-commits]

rjmccall added a comment.

Okay.  Thanks for the explanation, I think that was helpful.

I think I have two concerns about how we can use the existing infrastructure for VFE on Swift.

The first is that the existing infrastructure is definitely assuming that the emitted type-checked loads are to static offsets in the global constants you want to optimize.  The only flexibility here is that the address point doesn't have to end up being offset zero in the global constant.  In Swift, those conditions are only going to be true for pretty narrow cases: the caller needs to be able to lay out the class/protocol fully statically, and the emitter of the class/conformance needs to be emitting the metadata/wtable as a global object rather than an instantiation pattern, which generally means fully non-resilient and non-generic.  There are important cases which do look like that, but it's pretty limiting.

The only way around that that I can see is to break the assumption of a static offset.  You will need to tie the load to its loadee more symbolically, like by saying that you are conceptually accessing `Foo.bar` and annotating the field in the global as only accessed through loads tagged `Foo.bar`.  That would get you a certain amount of the optimization, like when a virtual function is never used virtually in the program, and then you can find a way to add in hierarchy analysis to get to parity with what's done for C++ now.

The second is that `!type` and `!vcall_visibility` are surprisingly inexpressive.  Do you really not to encode the inheritance hierarchy in `!type` metadata?  All that's there right now is compatibility that happens to start at the same offset, which I'm surprised is enough.  And `!vcall_visibility` applies to the entire global constant; you can't say that the parts of a v-table that correspond to a subclass are less visible.

If you don't need to worry about the non-static cases from the first point (which would require major changes), then I would solve your problem by tackling that last section and introducing new metadata which subsumes the information in `!type` and `!vcall_visibility`: list out all the regions in the global with explicit identities and address points, where identities describe their extents, super-identities, VFE-ability, and visibility of use.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108741/new/

https://reviews.llvm.org/D108741