================
@@ -4114,8 +4114,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
}
llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
- if (auto *IFunc = dyn_cast<llvm::GlobalIFunc>(ResolverConstant))
+ if (auto *IFunc = dyn_cast<llvm::GlobalIFunc>(ResolverConstant)) {
ResolverConstant = IFunc->getResolver();
+ // In Aarch64, default versions of multiversioned functions are mangled
to
+ // their 'normal' assembly name. This deviates from other targets which
+ // append a '.default' string. As a result we need to continue appending
+ // .ifunc in Aarch64.
+ // FIXME: Should Aarch64 mangling for 'default' multiversion function and
+ // in turn ifunc function match that of other targets?
----------------
tahonermann wrote:
Since `target_version` is new, I think it is reasonable to change its behavior
(via a different github PR).
I suspect the `target` behavior is an artifact of how the multiversion function
features evolved. My best guess is that the original implementation didn't
support an indirect function facility that enabled dynamic resolution from
outside a defining TU. Perhaps that was part of the motivation for adding
`target_clones`.
I just discovered that gcc doesn't support the `target` attribute when
compiling for C. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108964. I had
been under the impression that it just didn't support overloading on the
`target` attribute (but that the attribute still affected code generation).
Interesting that no warning is given for an ignored attribute. Here is the
example from the doc Elizabeth linked compiling as C.
https://godbolt.org/z/asfrhG51G.
https://github.com/llvm/llvm-project/pull/71706
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
