diff options
author | Alexandros Lamprineas <alexandros.lamprineas@arm.com> | 2025-06-02 11:04:00 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-06-02 11:04:00 +0100 |
commit | b3fd2ea88875e58c66dd67870ff822cedf2570cf (patch) | |
tree | c267a3575e52a159f224fe4ed465e1866a86ea38 /llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | |
parent | 68fd6f4eb86121d107dd4d0b282b11b48e82183b (diff) | |
download | llvm-b3fd2ea88875e58c66dd67870ff822cedf2570cf.zip llvm-b3fd2ea88875e58c66dd67870ff822cedf2570cf.tar.gz llvm-b3fd2ea88875e58c66dd67870ff822cedf2570cf.tar.bz2 |
[Clang][FMV] Stop emitting implicit default version using target_clones. (#141808)
With the current behavior the following example yields a linker error:
"multiple definition of `foo.default'"
// Translation Unit 1
__attribute__((target_clones("dotprod, sve"))) int foo(void) { return 1; }
// Translation Unit 2
int foo(void) { return 0; }
__attribute__((target_version("dotprod"))) int foo(void);
__attribute__((target_version("sve"))) int foo(void);
int bar(void) { return foo(); }
That is because foo.default is generated twice. As a user I don't find
this particularly intuitive. If I wanted the default to be generated in
TU1 I'd rather write target_clones("dotprod, sve", "default")
explicitly.
When changing the code I noticed that the RISC-V target defers the
resolver emission when encountering a target_version definition. This
seems accidental since it only makes sense for AArch64, where we only
emit a resolver once we've processed the entire TU, and only if the
default version is present. I've changed this so that RISC-V immediately
emmits the resolver. I adjusted the codegen tests since the functions
now appear in a different order.
Implements https://github.com/ARM-software/acle/pull/377
Diffstat (limited to 'llvm/lib/Bitcode/Writer/BitcodeWriter.cpp')
0 files changed, 0 insertions, 0 deletions