[cfe-dev] RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
Peter Collingbourne via cfe-dev
cfe-dev at lists.llvm.org
Fri Mar 4 12:47:11 PST 2016
On Fri, Mar 4, 2016 at 9:32 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> > On Feb 29, 2016, at 1:53 PM, Peter Collingbourne <peter at pcc.me.uk>
> > Hi all,
> > I'd like to make a proposal to implement the new vtable ABI described in
> > PR26723, which I'll call the relative ABI. That bug gives more details
> > justification for that ABI.
> > The user interface for the new ABI would be that -fwhole-program-vtables
> > would take an optional value indicating which aspects of the program have
> > whole-program scope. For example, the existing implementation of
> > vcall optimization allows external code to call into translation units
> > compiled with -fwhole-program-vtables, but does not allow external code
> > derive from classes defined in such translation units, so you could
> > the current behaviour with "-fwhole-program-vtables=derive", which means
> > that derived classes are not allowed from outside the program. To request
> > the new ABI, you can specify "-fwhole-program-vtables=call,derive",
> > which means that calls and derived classes are both not allowed from
> > outside the program. "-fwhole-program-vtables" would be short for
> > "-fwhole-program-vtables=call,derive,anythingelseweaddinfuture".
> > I'll also make the observation that the new ABI does not require LTO or
> > whole-program visibility at compile time; to decide whether to use the
> > ABI for a class, we just need to check that it and its bases are not in
> > whole-program-vtables blacklist.
> > At the same time, I'd like to change how virtual calls are represented in
> > the IR. This is for a few reasons:
> > 1) Would allow whole-program virtual call optimization to work well with
> > relative ABI. This ABI would complicate the IR at call sites and make
> > harder to do matching and rewriting.
> > 2) Simplifies the whole-program virtual call optimization pass.
> Currently we
> > need to walk uses in the IR in order to determine the slot and callees
> > each call site. This can all be avoided with a simpler representation.
> > 3) Would make it easier to implement dead virtual function stripping.
> This would
> > involve reshaping any vtable initializers and rewriting call
> > sites. Implementing this correctly is harder than it needs to be
> > of the current representation.
> > My proposal is to add the following new intrinsics:
> Thanks, I'm really glad you're moving forward on improving the IR
> representation so fast after our previous discussion. The use of these
> intrinsics looks a lot more friendly to me! :)
> (even if I still does not make sense of the "bitset" terminology to
> represent the hierarchy for the metadata part)
> > i32 @llvm.vtable.slot.offset(metadata, i32)
> > This intrinsic takes a bitset name B and an offset I. It returns the byte
> > offset of the I'th virtual function pointer in each of the vtables in B.
> > i8* @llvm.vtable.load(i8*, i32)
> Why is the vtable.load taking a byte offset instead of a slot index
> directly? (the IR could be simpler by not requiring to call
> @llvm.vtable.slot.offset() for every @llvm.vtable.load())
I decided to split these in order to support virtual member function
pointers correctly. In the Itanium ABI, member function pointers use a byte
offset. The idea is that llvm.vtable.slot.offset would be used to create a
member function pointer, while llvm.vtable.load would be used to call it
(see also the getmfp and callmfp examples).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev