Bump libxsmm

[adam-smnk]

No description provided.

[alheinecke]

LGTM

[adam-smnk]

@alheinecke Rerunning benchmark again but I see regressions on baseline xsmm_dnn_mlp performance.

[alheinecke]

Nothing changed in libxsmm-dnn. Which one regress?

[adam-smnk]

Nothing changed in libxsmm-dnn. Which one regress?

BASE: gemm_f32_dnn_target, gemm_bf16_dnn_target, mlp_f32_dnn_target, mlp_bf16_dnn_target
And all their OMP f32 and bf16 counterparts e.g., gemm_bf16_omp_2_dnn

MLIR models look fine with no change.

[alheinecke]

Oh... the libxsmm-dnn commit was so old and our benchmarks are not meaningful as we discussed a couple of month back.... (for both libxsmm-dnn and MLIR). libxsmm-dnn uses now (6 months ago commit) by default SFC and this hurts the tiny test we are running as it causes more cache to cache transfers. There are now two options: a) defining more reasonable benchmarks b) disabling SFC in libxsmm by exporting LIBXSMM_DNN_DISABLE_SFC=1

[adam-smnk]

Alright, I'll try the env var just for consistency and we should revisit benchmarks separately altogether.

[adam-smnk]

LIBXSMM_DNN_DISABLE_SFC=1 somewhat improved bf16 but fp32 is still much worse than before.

[adam-smnk]

Anyway, it's not a blocker as MLIR execution is unaffected.
Let's merge for now and we can revisit these settings later.

[alheinecke]

I guess it might be also related to argument changes in libxsmm-dnn (flat layouts vs, packed). It's nearly a 1 year bump....

[alheinecke]

we can also only bump libxsmm and not libxsmm-dnn...

[adam-smnk]

we can also only bump libxsmm and not libxsmm-dnn...

Yup, just bumping libxsmm. No regressions in benchmarks.