> On Feb 3, 2017, at 1:27 PM, John McCall <rjmcc...@apple.com> wrote:
>
>> On Feb 3, 2017, at 4:18 PM, Andrew Trick <atr...@apple.com
>> <mailto: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.
I was briefly over-thinking the problem… we could hoist the part that wasn’t
dependent on the `isa`. That’s probably not important, and if it were, we could
still hoist the cache lookup.
This option does seem to have the lowest immediate ABI cost (one symbol per
class) with a tremendous amount of flexibility for optimizing both the dispatch
code and the metadata representation.
-Andy
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
