> On Feb 3, 2017, at 4:18 PM, Andrew Trick <atr...@apple.com> wrote:
>> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>>>> #3b. (lazy resolution) Offset tables can be completely localized.
>>>>
>>>> method_index = immediate
>>>> { // common per-class method lookup
>>>> isa = load[obj]
>>>> offset = load[@local_class_method_table + method_index]
>>>> if (!isInitializedOffset(offset)) {
>>>> offset = @resolveMethodOffset(@class_id, method_index)
>>>> store [@local_class_method_table + method_index]
>>>> }
>>>> if (isVtableOffset(offset))
>>>> method_entry = load[isa + offset]
>>>> else
>>>> method_entry = @resolveMethodAddress(isa, @class_id, method_index)
>>>> }
>>>> call method_entry
>>>
>>> The size of @local_class_method_table is not statically knowable.
>>> Fortunately, it doesn't matter, because this mechanism does not actually
>>> care about the table being contiguous; the lookup function could be
>>> passed a per-method cache variable. This would also allow the lookup
>>> function to be shared between classes.
>
> Hmm... I thought the local method offset table size could be statically
> knowable because it will only be accesd for methods that were publicly
> available at build time, based on the sorted method index.
Sure, I mean, you can pick a table size that's sufficient for all the offsets
that will be passed. That would save a few instructions at call sites, at the
cost of requiring the resolvers to be per-class.
> We could simplify the method resolution API with a single exported symbol
> per-class (maybe that's what you're getting at):
>
> method_entry = resolveMethodAddress_ForAClass(isa, method_index,
> &vtable_offset)
Right, this is what I was thinking.
> The problem with that is the client-side code can’t hoist and combine the
> method offset lookup anymore.
Why not? vtable_offset is basically an opaque cache here. Sure, technically
the call isn't readnone anymore, but it's an innocuous violation like adding
memoization to sin().
Or is there some finer-grained hoisting you're imagining than the entire call?
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
