<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 9:32 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><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>
> On Feb 29, 2016, at 1:53 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I'd like to make a proposal to implement the new vtable ABI described in<br>
> PR26723, which I'll call the relative ABI. That bug gives more details and<br>
> justification for that ABI.<br>
><br>
> The user interface for the new ABI would be that -fwhole-program-vtables<br>
> would take an optional value indicating which aspects of the program have<br>
> whole-program scope. For example, the existing implementation of whole-program<br>
> vcall optimization allows external code to call into translation units<br>
> compiled with -fwhole-program-vtables, but does not allow external code to<br>
> derive from classes defined in such translation units, so you could request<br>
> the current behaviour with "-fwhole-program-vtables=derive", which means<br>
> that derived classes are not allowed from outside the program. To request<br>
> the new ABI, you can specify "-fwhole-program-vtables=call,derive",<br>
> which means that calls and derived classes are both not allowed from<br>
> outside the program. "-fwhole-program-vtables" would be short for<br>
> "-fwhole-program-vtables=call,derive,anythingelseweaddinfuture".<br>
><br>
> I'll also make the observation that the new ABI does not require LTO or<br>
> whole-program visibility at compile time; to decide whether to use the new<br>
> ABI for a class, we just need to check that it and its bases are not in the<br>
> whole-program-vtables blacklist.<br>
><br>
> At the same time, I'd like to change how virtual calls are represented in<br>
> the IR. This is for a few reasons:<br>
><br>
> 1) Would allow whole-program virtual call optimization to work well with the<br>
>   relative ABI. This ABI would complicate the IR at call sites and make it<br>
>   harder to do matching and rewriting.<br>
><br>
> 2) Simplifies the whole-program virtual call optimization pass. Currently we<br>
>   need to walk uses in the IR in order to determine the slot and callees for<br>
>   each call site. This can all be avoided with a simpler representation.<br>
><br>
> 3) Would make it easier to implement dead virtual function stripping. This would<br>
>   involve reshaping any vtable initializers and rewriting call<br>
>   sites. Implementing this correctly is harder than it needs to be because<br>
>   of the current representation.<br>
><br>
> My proposal is to add the following new intrinsics:<br>
<br>
</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>
(even if I still does not make sense of the "bitset" terminology to represent the hierarchy for the metadata part)<br>
<span class=""><br>
><br>
> i32 @llvm.vtable.slot.offset(metadata, i32)<br>
><br>
> This intrinsic takes a bitset name B and an offset I. It returns the byte<br>
> offset of the I'th virtual function pointer in each of the vtables in B.<br>
><br>
> i8* @llvm.vtable.load(i8*, i32)<br>
<br>
</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></blockquote><div><br></div><div>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><br></div><div>Thanks,</div><div>Peter</div></div>
</div></div>