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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to