xsmm - update for function name change

[jeremylt]

This branch fixes #1462

It turns out it was just a name change. We can merge once libXSMM releases their new version, or sooner if needed.

[jeremylt]

I think I contributed a macro to them like ours. I think we need to ask them if a release is coming soon and then we can add a macro to that tensor file that uses their version marco

[sebastiangrimberg]

Is there a way to identify the version? It seems like only the patch version has changed, like libxsmm main is now at 1.17-3708, and I assume 1.18 is next? Is there a better way?

I believe v2.0 is next and that's what they are preparing for. libxsmm.h defines LIBXSMM_VERSION (and LIBXSMM_VERSION_MAJOR which should allow us to check. This is populated from the version.txt file in the libxsmm repo, which currently is at 1.17-3708 but I think should be updated to 2.0 when released.

[jeremylt]

libXSMM should be making a new release in roughly 2-3 months time

[jeremylt]

The LIBXSMM release is taking a while. What about merging this fix now since we're already requiring a min version that isn't the latest release. Then we can switch the min version to the next LIBXSMM release when it happens

[sebastiangrimberg]

I agree with that. In Palace we are just applying the changes from this PR as a patch for all LIBXSMM builds (https://github.com/awslabs/palace/blob/main/extern/patch/libCEED/patch_xsmm.diff).

[sebastiangrimberg]

Okay, but we should document the min version somewhere more than CI, as this bleeding edge non-release version may be surprising to users.

This is true. Spack builds will fail by default too unless the user builds with libxsmm@=main explicitly since the newest tagged version in the registry is also too old.