bug: (libxsmm) fix the little matmul use case

[qaco]

The use case contained 4 bugs according to computing a matmul:
1- Bad order of vfmadd parameters (AT&T syntax instead of Intel syntax)
2- vfmadd231pd instead of vfmadd231ps (double precision instead of single precision)
3- Incosistency between B dimensions (4x2) and C dimensions (4x4)
4- (performance bug, avoidable dependency) Load all B columns in the same register

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.31%. Comparing base (403f084) to head (3250e56).
Report is 5 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3956   +/-   ##
=======================================
  Coverage   91.31%   91.31%           
=======================================
  Files         468      468           
  Lines       58144    58144           
  Branches     5582     5580    -2     
=======================================
+ Hits        53094    53096    +2     
+ Misses       3623     3622    -1     
+ Partials     1427     1426    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[compor]

I am not sure how to review this as (apart from the multiple issues), I have no way of verifying (easily) the above.

There are two aspects:

1. Maybe it is time to invest in an "experiments repo"; I can see this being easily called in from a main() stub that provides the inputs. Moreover, I have a machine here that can run those if needed.
2. I can't pretend that I understand the assembly code's performance, just by reading it on a PR, although it is still easily parsable by a human

Based on these take my "Approval" at face value.

[emmau678]

It looks good to me

[qaco]

I am not sure how to review this as (apart from the multiple issues), I have no way of verifying (easily) the above.

There are two aspects:

1. Maybe it is time to invest in an "experiments repo"; I can see this being easily called in from a `main()` stub that provides the inputs. Moreover, I have a machine here that can run those if needed.

2. I can't pretend that I understand the assembly code's performance, just by reading it on a PR, although it is still easily parsable by a human

Based on these take my "Approval" at face value.

Fully agree on your idea to enhance the testing framework. Do you think this "validation" step should be performed in a separate repo or in a subdirectory of xdsl/tests ?

[compor]

Fully agree on your idea to enhance the testing framework. Do you think this "validation" step should be performed in a separate repo or in a subdirectory of xdsl/tests ?

I don't think there is a perfect solution, but we've had success with a separate repo when using a setup that has quite hefty dependencies.

I think the case here is much simpler, although not without overhead (syncing the repos, etc.), but such is life :-)