Remove __attribute__((target_clones)) requirement in function prototype

[HFTrader]

Let's say I have a library that I want to share with multiple targets

#include <array>
#include <cstdio>

using Vector = std::array<float, 2>;
using Matrix = std::array<float, 4>;

__attribute__((target_clones("default","arch=core2","arch=znver2")))
Vector multiply(const Matrix& m, const Vector& v) {
    Vector r;
    r[0] = v[0] * m[0] + v[1] * m[2];
    r[1] = v[0] * m[1] + v[1] * m[3];
    return r;
}

and I want to use that as below

#include <array>
#include <cstdio>

using Vector = std::array<float, 2>;
using Matrix = std::array<float, 4>;

Vector multiply(const Matrix& m, const Vector& v);

int main() {
    Matrix m{1,2,3,4};
    Vector v{1,2};
    Vector r = multiply(m,v);
    printf( "%f %f\n", r[0], r[1] );
}

Godbolt project: https://godbolt.org/z/3hd4MrzsG

GCC will be happy to compile and link the above two files together but Clang++ will complain about undefined references.

ld: CMakeFiles/example.dir/example.cpp.o: in function `main':
example.cpp:(.text+0x2a): undefined reference to `multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&)'

To make this work, I have to add all the targets in the prototype as well as in

#include <array>
#include <cstdio>

using Vector = std::array<float, 2>;
using Matrix = std::array<float, 4>;

__attribute__((target_clones("default","arch=core2","arch=znver2")))
Vector multiply(const Matrix& m, const Vector& v);

int main() {
    Matrix m{1,2,3,4};
    Vector v{1,2};
    Vector r = multiply(m,v);
    printf( "%f %f\n", r[0], r[1] );
}

Looking at the object files generated, it seeems that the main difference is that GCC generates an indirect link for the naked prototype while Clang generate an indirect link to .ifunc and that requires knowledge of the target attributes.

$ diff nm.gcc nm.clang
3,4d2
<                 U _GLOBAL_OFFSET_TABLE_
<                 U __stack_chk_fail
6,13c4,11
< i multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&)
< t multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .arch_cascadelake.3]
< t _Z8multiplyRKSt5arrayIfLm4EERKS_IfLm2EE.arch_core2.0
< t multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .arch_haswell.2]
< t multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .arch_sandybridge.1]
< t _Z8multiplyRKSt5arrayIfLm4EERKS_IfLm2EE.arch_znver1.4
< t _Z8multiplyRKSt5arrayIfLm4EERKS_IfLm2EE.arch_znver2.5
< t multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .default.6]
---
> T multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .arch_cascadelake.3]
> T _Z8multiplyRKSt5arrayIfLm4EERKS_IfLm2EE.arch_core2.0
> T multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .arch_haswell.2]
> T multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .arch_sandybridge.1]
> T _Z8multiplyRKSt5arrayIfLm4EERKS_IfLm2EE.arch_znver1.4
> T _Z8multiplyRKSt5arrayIfLm4EERKS_IfLm2EE.arch_znver2.5
> T multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .default.6]
> i multiply(std::array<float, 4ul> const&, std::array<float, 2ul> const&) [clone .ifunc]
20d17
< r std::piecewise_construct

The request is that Clang emits targets in a way that the target attributes won't be necessary in the function declaration/prototype.

[llvmbot]

@llvm/issue-subscribers-c-1

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[MaskRay]

Clang's current behavior is a result of the symbol difference: https://maskray.me/blog/2023-02-05-function-multi-versioning

I wonder whether GCC intentionally supports the use case. My may need a clarification from them.

[HFTrader]

GCC answered

Yes this is the correct behavior for this attribute.

Looks like it was not implemented the same way in clang, report it to them.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109047

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#index-target_005fclones-function-attribute

It also creates a resolver function (see the ifunc attribute above) that dynamically selects a clone suitable for current architecture. The resolver is created only if there is a usage of a function with target_clones attribute.

[lawben]

I just stumbled across this in a project that I'm working on (with Clang/LLVM 18). This is really not my area of expertise, but it feels like not exporting the "naked" symbol somewhat defeats the "I will resolve this for you" purpose of this feature. The symbol is created, but it is not exported (at least according to nm it is a local symbol). Currently, I can only use target_clones within the same compilation unit but not from a library, which I would like to do.

Is there any technical reason to not export the symbol? If GCC does this, and there is no technical reason to avoid doing it, not exporting the symbol feels more like a bug than a "missing feature/enhancement".

As nothing has happened here for over a year: is anybody working on this or is there a decision on how to move forward? I'm happy to help, as I have a specific use-case that needs exactly this feature.

[jroelofs]

cc @labrinea: I vaguely remember we talked about the corresponding problem for target_version, but I don't remember the resolution.

[jroelofs]

• [FMV] incorrect codegen when there is no TU-local caller #81494
• [FMV] mangling of forward-declared multi-versioned callee differs between gcc and clang #81043

[jroelofs]

I think this has been fixed. @HFTrader's original example works now: https://godbolt.org/z/3hd4MrzsG