Repository navigation
NEON64 code link error if gcc -O1 or -O0 #573
Description
A simple test code
#include <cstddef>
#include <xsimd/xsimd.hpp>
int main() {
using simd_batch = xsimd::batch<int8_t, xsimd::neon64>;
simd_batch a(1);
simd_batch b(2);
simd_batch c = a | b;
return xsimd::any(b < c);
}Compile with gcc -O1 or -O0
$ g++ -O1 neon-debug.cc -I./include -march=armv8-a -std=c++11
/tmp/cc89XtTV.o: In function `main':
neon-debug.cc:(.text+0x10): undefined reference to `vorrq_s8(__Int8x16_t, __Int8x16_t)'
neon-debug.cc:(.text+0x1c): undefined reference to `vcltq_s8(__Int8x16_t, __Int8x16_t)'
collect2: error: ld returned 1 exit statusOther info
- Tested with gcc-7.5, 9.3, 10.3, all failed
- OK if -O2, -O3
- OK for clang, no matter -O?
- Error log from apache arrow ci: https://app.travis-ci.com/github/apache/arrow/jobs/540146067#L1073
Activity
cyb70289 commentedon Sep 29, 2021
Looks the error is from below static dispatcher code:
https://github.com/xtensor-stack/xsimd/blob/master/include/xsimd/arch/xsimd_neon.hpp#L42-L44
Without optimization, gcc treats the returned neon func (vorrq_s8, ...) as a function pointer, and tries to find the function at link time, which causes the error.
From this example code: https://godbolt.org/z/orsqz7xTn, obviously gcc thinks vorrq_s8 is a function implemented somewhere.
cyb70289 commentedon Sep 29, 2021
@JohanMabille @serge-sans-paille do you have ideas how to address this issue?
serge-sans-paille commentedon Sep 29, 2021
@cyb70289 can you try flagging the function as
__attribute__((always_inline))?cyb70289 commentedon Sep 29, 2021
Flagging this function as always_inline? I tried but it doesn't help.
__attribute__((always_inline)) inline return_type<U> apply(U lhs, U rhs) constcyb70289 commentedon Sep 29, 2021
I filed a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102526
As a workaround, I think xsimd users (e.g., apache arrow) can bypass simd code for gcc debug build on aarch64. This should be acceptable as you don't care about performance for debug build.
cyb70289 commentedon Sep 30, 2021
Gcc community does not think it's a bug, there was a discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100005
I'm inclined to agree with the community. Taking address of an intrinsic does looks a bit strange.
One approach to fix this issue is to wrap the intrinsic with a lambda, which gives a pseudo address
to intrinics. See below example.
Current code:
Updated code:
I've tested this method works okay with -O0, and incurs no penalty with higher optimization levels.
What's your opinion? @serge-sans-paille @JohanMabille
If you think it's okay, I'm glad to upload a PR.
serge-sans-paille commentedon Sep 30, 2021
Fix Neon build error if gcc -O0 (#578)