complexity of matching symbol names to version scripts

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Mon May 2 18:38:25 PDT 2016


On Mon, May 2, 2016 at 5:39 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Mon, May 2, 2016 at 5:26 PM, Rui Ueyama via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> What I'm worrying is this. Let N be the number of symbols in all input
>> files and M be the number of symbols that appear in version scripts.
>>
>> If there's no pattern matching in version symbol script, then the cost of
>> setting versions is O(M). We call SymbolTable::find(StringRef) for each
>> symbol from version scripts and set a version to the return value.
>>
>> But if we allow patterns, the cost becomes O(N). Even though is better
>> than O(N*M), it is a large number. M is order of hundreds or thousands, but
>> N can be as large as order of millions.
>>
>> So I think we should avoid pattern matching to symbols.
>>
>
> What do we do if the user passes a version script that has a pattern
> match? Emit an error?
>

I'd think so, so that users can update their version script files. We could
fall back to the O(N) algorithm with a warning to say that it is slow due
to wildcards, but we should avoid even doing that until it's proved that
it's truly unavoidable.

-- Sean Silva
>
>
>>
>>
>> On Sat, Apr 30, 2016 at 7:46 PM, Rafael EspĂ­ndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> No idea why this just came to mind, but anyway:
>>>
>>> I remember you mentioning that one annoying thing about version
>>> scripts is the need to match each symbol against multiple possible
>>> regular expressions (globs?).
>>>
>>> But I just remembered that that can be done efficiently. Multiple
>>> regular expressions can be tested at once. They are all just NFAs :-)
>>>
>>> Cheers,
>>> Rafael
>>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160502/20741622/attachment.html>


More information about the llvm-commits mailing list