Eltwise unary reduce fails to validate on ARM64 baseline

[hfp]

Unary reduce fails to validate on ARM64 baseline (Jetson).

./eltwise_unary_reduce 9 133 9 1 0 0 1 F32 42 0 1 0

The output on our Jetson system looks like:

CL is: 9 133 9 1 0 0 1 F32 42 0 1 0 0
Running reference reduce kernel...
JITing reduce kernel...
Calling JITed reduce cols idx kernel...
##########################################
# FP32 Correctness - Eltwise red. colsidx#
##########################################
L1 reference  : 8.76750075817108154296875
L1 test       : 8.76750075817108154296875
L2 abs.error  : 0.000000000000000000000000
L2 rel.error  : 0.000000000000000000000000
Linf abs.error: 0.000000000000000000000000
Linf rel.error: 0.000000000000000000000000
Check-norm    : 0.000000000000000000000000

##########################################
# Arg idx correctness  #
##########################################
L1 reference  : 457
L1 test       : 8313363870940921856
L2 abs.error  : 8313363870940921856.000000000000000000000000
L2 rel.error  : 923707096771213568.000000000000000000000000
Linf abs.error: 8313363870940921856.000000000000000000000000
Linf rel.error: 923707096771213568.000000000000000000000000
Check-norm    : 42829068818151664.000000000000000000000000

The reference value seems to be a valid index (idx=457), i.e., the JIT'ted kernel seems to be the cause.

Note: the M1 system does not expose the issue even when forced to baseline, i.e., LIBXSMM_TARGET=arm64.

[hfp]

Btw, you can debug on ARM without running into the SIGILL-trap (used in our CPUID-detect) by setting LIBXSMM_TARGET, e.g., LIBXSMM_TARGET=arm64. This feature (improved debug) is part of main branch (not yet in main_stable).

I recommend debugging this issue using main branch.

[alheinecke]

we right now are fixing main_stable, this will be fixed when main is ready to be merged.

[hfp]

To confirm, this is perhaps an old issue and it is present in main_stable branch also. There should be no significant difference between code generators in main and main_stable. It is just easier to debug main prior to backporting aforementioned enhancement (setting LIBXSMM_TARGET omits certain flow in CPUID on ARM64).

[hfp]

This seems to rarely fail on SVE also, e.g., https://buildkite.com/intel/libxsmm-arm-graviton3/builds/584#01891aa8-6360-4025-8843-808693223dc2. Some investigation is needed to confirm this is the same issue as on AArch64 baseline.

[hfp]

To confirm with current main_stable on pcl-jetsonagx:

cd libxsmm && git checkout main_stable && git pull
make DBG=1 -j8 && cd samples/eltwise && make DBG=1 -j8
./eltwise_unary_reduce 9 133 9 1 0 0 1 F32 42 0 1 0

This yields 457 (L1 reference) vs. 8313363870940921856 (L1 test).