[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

Itay Bookstein via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 4 09:53:05 PDT 2021


nextsilicon-itay-bookstein added a comment.

That feature already exists - use a plain old function declaration :)

My mental model for this is like this:
memcpy one of the is the most widely popular APIs commonly implemented as an ifunc. In clients of this API, it's just a plain old function declaration. In the implementer of this API, it's an ifunc with a defined resolver. Nothing new here.
It's true that this usage usually crosses a dynamic-linking boundary (rather than static linking), but a lot of the times dynamic linking and static linking are set up to mirror each other in behavior.

What I'm proposing is as follows. I really haven't read the existing implementation yet, so I'm not sure if it makes 100% sense in terms of it, but bear with me:

- When processing cpu_specific, emit a plain old function declaration "x.ifunc";
- When processing cpu_dispatch:
  1. Create an unnamed ifunc (call it `GI`)
  2. Call CodeGenModule::GetGlobalValue
  3. If the result was null, set the name of the ifunc and continue
  4. If the result wasn't null (call it `F`), use `GI->takeName(F); F->replaceAllUsesWith(GI);`
- Throughout, references against the multiversioned symbol are bound against the correctly named global. It just so happens that it could either begin its life as an ifunc and remain that way, begin its life as function declaration and remain that way, or begin its life as a function declaration and get upgraded (by RAUW) to an ifunc.

You can think of this as mirroring the behavior of the IR linker - linking a bitcode module containing an ifunc definition into an existing module where there's a function declaration with the same name as the ifunc simply tramples over the function declaration (RAUWs it with the linked-in ifunc). This is exactly what happens in `llvm/test/Linker/ifunc.ll` for `bar`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349



More information about the llvm-commits mailing list