[PATCH] D42216: Use New Module Metadata String "AvoidPLT" to avoid calls via PLT

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 24 14:19:17 PST 2018


Could you please rebase this on top of r323297?

Thanks,
Rafael

Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:

> Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:
>
>> My memory in these areas is fuzzy. Do we never create a GV for a call to
>> an intrinsic or do we lose it at some point in the codegen path? If it is
>> lost, could we track it a bit longer?
>>
>> For this patch, is there any other case when GV is null? If that only
>> happens when calling an intrinsic shouldAssumeDSOLocal can use that to
>> know that it is a call.
>>
>> Maybe it can always return false if GV is null?
>>
>> There are 3 ways of calling a function:
>>
>> call foo
>> call foo at plt
>> call *foo at got
>>
>> if shouldAssumeDSOLocal returns true, we are supposed to use the first
>> one. If it returns false, one of the last two.
>>
>> Now, "call "foo" is almost identical to "call foo at plt" as the linker can
>> convert plt calls if the target is local. If the only case when GV is
>> null is a call to an intrinsic, it is safe to return false.
>
> I am experimenting with returning false when GV is null.
>
> The first problem I noticed is coff. For coff we always assume that a
> null GV is local, which is a bit surprising. I guess the compiler
> runtime is always static on windows?
>
> This indicates that TargetMachine::shouldAssumeDSOLocal will never go
> away completely, but if we can limit to just test the file type and
> only when GV is null that would still be a good improvement.
>
> I will report in a minute on the result of the experiment.
>
> Cheers,
> Rafael


More information about the llvm-commits mailing list