https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121875
Bug ID: 121875
Summary: LoongArch: Inlining A into B should be allowed if the
target feature of A is a subset of B's
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
$ cat t.c
[[gnu::always_inline]] inline void f() {}
[[gnu::target("lasx")]] int main() {f();}
$ LANG= ~/gcc-dev/bin/gcc t.c
t.c: In function 'main':
t.c:1:36: error: inlining failed in call to 'always_inline' 'f': target
specific option mismatch
1 | [[gnu::always_inline]] inline void f() {}
| ^
t.c:2:37: note: called from here
2 | [[gnu::target("lasx")]] int main() {f();}
| ^~~
Other targets allow things like this, for example on x86_64:
[[gnu::always_inline]] inline void f() {}
[[gnu::target("avx")]] int main() {f();}
is accepted. And aarch64:
[[gnu::always_inline]] inline void f() {}
[[gnu::target("+sve")]] int main() {f();}
is accepted.
Clang also accepts the original test case, so it seems the behavior of
LoongArch GCC is inconsistent from all other compilers.
And the LoongArch GCC behavior also severely limits the usefulness of the
target attribute, for example it's preventing us from implementing a run-time
implementation dispatch in Highway because the LASX optimized routines are
calling generic always_inline functions, so to make them work those generic
functions have to be built with LASX enabled as well, causing a hard dependency
on LASX and rendering the runtime dispatch pointless.
Thus the behavior should be changed.
