<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 4, 2016, at 12:47 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Fri, Mar 4, 2016 at 9:32 AM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class=""><div class="h5"><br class="">> On Feb 29, 2016, at 1:53 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:<br class="">><br class="">> Hi all,<br class="">><br class="">> I'd like to make a proposal to implement the new vtable ABI described in<br class="">> PR26723, which I'll call the relative ABI. That bug gives more details and<br class="">> justification for that ABI.<br class="">><br class="">> The user interface for the new ABI would be that -fwhole-program-vtables<br class="">> would take an optional value indicating which aspects of the program have<br class="">> whole-program scope. For example, the existing implementation of whole-program<br class="">> vcall optimization allows external code to call into translation units<br class="">> compiled with -fwhole-program-vtables, but does not allow external code to<br class="">> derive from classes defined in such translation units, so you could request<br class="">> the current behaviour with "-fwhole-program-vtables=derive", which means<br class="">> that derived classes are not allowed from outside the program. To request<br class="">> the new ABI, you can specify "-fwhole-program-vtables=call,derive",<br class="">> which means that calls and derived classes are both not allowed from<br class="">> outside the program. "-fwhole-program-vtables" would be short for<br class="">> "-fwhole-program-vtables=call,derive,anythingelseweaddinfuture".<br class="">><br class="">> I'll also make the observation that the new ABI does not require LTO or<br class="">> whole-program visibility at compile time; to decide whether to use the new<br class="">> ABI for a class, we just need to check that it and its bases are not in the<br class="">> whole-program-vtables blacklist.<br class="">><br class="">> At the same time, I'd like to change how virtual calls are represented in<br class="">> the IR. This is for a few reasons:<br class="">><br class="">> 1) Would allow whole-program virtual call optimization to work well with the<br class="">> relative ABI. This ABI would complicate the IR at call sites and make it<br class="">> harder to do matching and rewriting.<br class="">><br class="">> 2) Simplifies the whole-program virtual call optimization pass. Currently we<br class="">> need to walk uses in the IR in order to determine the slot and callees for<br class="">> each call site. This can all be avoided with a simpler representation.<br class="">><br class="">> 3) Would make it easier to implement dead virtual function stripping. This would<br class="">> involve reshaping any vtable initializers and rewriting call<br class="">> sites. Implementing this correctly is harder than it needs to be because<br class="">> of the current representation.<br class="">><br class="">> My proposal is to add the following new intrinsics:<br class=""><br class=""></div></div>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! :)<br class="">(even if I still does not make sense of the "bitset" terminology to represent the hierarchy for the metadata part)<br class=""><span class=""><br class="">><br class="">> i32 @llvm.vtable.slot.offset(metadata, i32)<br class="">><br class="">> This intrinsic takes a bitset name B and an offset I. It returns the byte<br class="">> offset of the I'th virtual function pointer in each of the vtables in B.<br class="">><br class="">> i8* @llvm.vtable.load(i8*, i32)<br class=""><br class=""></span>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())<br class=""></blockquote><div class=""><br class=""></div><div class="">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).</div></div></div></blockquote><div><br class=""></div><div>Make sense! Thanks.</div><div><br class=""></div><div>-- </div><div>Mehdi</div><div><br class=""></div></div></body></html>