Stream: t-compiler/wg-mir-opt

Topic: optimization idea: deduplicate vtables

oli (May 17 2019 at 06:29, on Zulip):

The vtable of Foo contains the exact same bits that the vtable of Bar has (plus more) if Foo: Bar (and no other trait bounds). In llvm we end up with two vtables which each require their own static memory slot. We know for a fact though that duplicating or deduplicating vtables is perfectly legal (since duplicating happens across crates, see docs and discussion on the ptr::eq method). Before lowering vtables to llvm, we could have a table of existing vtables and look through it to find any vtables that start with the exact memory of the entire vtable we currently want to lower. If we find that, we just yield the already lowered (bigger or equal) vtable. We can even go further at some point and check whether vtables for different types can be deduplicated (which should be possible if all methods have the exact same body), but the low hanging fruit of deduplicating vtables for a single type but multiple traits is something I think we could fix and that -Os could benefit from

Wesley Wiser (May 17 2019 at 11:53, on Zulip):

How does that interact with rfc 2580? If I ptr::metadata() a &Bar and get back a VTable<Foo> I guess that would be fine now.

Wesley Wiser (May 17 2019 at 11:53, on Zulip):

But if we extended the API's in the future to allow introspecting the available methods, then it would be very confusing/potentially a bug.

oli (May 17 2019 at 12:10, on Zulip):

You'd still get a Vtable<Bar> in the type system. It's just a deduplication of the backing memory of the vtables. So the pointers will alias, not sure if that is a problem

Wesley Wiser (May 17 2019 at 12:12, on Zulip):

I guess since Vtable::Metadata doesn't implement Eq or PartialEq, there's no safe way of discovering that

Wesley Wiser (May 17 2019 at 12:12, on Zulip):

Seems reasonable then

kennytm (May 18 2019 at 16:32, on Zulip):

in RFC 2580 the Metadata needs to impl Ord which implies impl Eq + PartialOrd<Self> + PartialEq<Self>

kennytm (May 18 2019 at 16:33, on Zulip):

but even with the same type Foo, the vtable constructed from crate A and that from crate B could be in different locations

kennytm (May 18 2019 at 16:37, on Zulip):

basically, if you think this feature is going to affect code relying on vtable equality, perhaps those code are already buggy themselves.

Last update: Sep 27 2020 at 13:30UTC