[PATCH] D139163: Utils: Add utility pass to lower ifuncs

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 22 11:56:42 PST 2022


arsenm added a comment.

In D139163#4013814 <https://reviews.llvm.org/D139163#4013814>, @arsenm wrote:

> In D139163#4013806 <https://reviews.llvm.org/D139163#4013806>, @MaskRay wrote:
>
>> In D139163#4012919 <https://reviews.llvm.org/D139163#4012919>, @arsenm wrote:
>>
>>> In D139163#4012366 <https://reviews.llvm.org/D139163#4012366>, @MaskRay wrote:
>>>
>>>> What's the motivation for piggybacking the functionality on top of ifunc? Does AMDGPU want to use ifunc to do something special?
>>>
>>> I'm considering it as an option to deal with some of the builtin library complexity, so it would be used with a restricted set of known functions. I'm not planning on exposing this as a user facing feature. The resolver would be known trivial after link and optimize out most of the time, but needs a fallback where a global constructor will do just fine.
>>
>> Is there a reason that reusing ifunc is better than a global function pointer? Here is an example of a global function pointer.
>> I just added it to https://maskray.me/blog/2021-01-18-gnu-indirect-function#alternative
>
> First of all, the language doesn't allow function pointers. Second, the idea would be to let clang emit the resolver with target_clones.

For the moment this is just used as a strategy for llvm-reduce to delete ifuncs, I haven't started work on really using it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139163/new/

https://reviews.llvm.org/D139163



More information about the llvm-commits mailing list