WIP: Handle defective implementations of float functions. #68
Conversation
|
If the check works this sounds right, but this is only half of the truth. Behaving like the accelerate framework needs to change the return type of the flexiblas function as well. |
This is a very crude attempt to check whether BLAS functions that should return single-precision floating point values actually do that. Some implementations (like Apple Accelerate) don't do that. See mpimd-csc#65. This is mainly meant for early feedback.
mmuetzel
force-pushed
the
accelerate-float
branch
from
1710c58 to
526b722
Compare
|
I fixed a couple of issues with the test for the behavior of |
| if (intel_interface) { | ||
| #ifdef FLEXIBLAS_INTEGER8 | ||
| void (*sdot)(float *, int64_t *, float *, int64_t *, float *, int64_t *); | ||
| #else | ||
| void (*sdot)(float *, int32_t *, float *, int32_t *, float *, int32_t *); | ||
| #endif | ||
|
|
||
| sdot(&retval, &n, x, &one, y, &one); |
There was a problem hiding this comment.
if (intel_interface) this could just return 0, right?
There was a problem hiding this comment.
I don't know how many implementations of BLAS/LAPACK could potentially have this defect. The only one I know for sure is Apple Accelerate (that doesn't use the Intel calling convention afaict).
I figured that the safest would be to check in any case. But if you feel confident that no implementation that uses the Intel calling convention could potentially be affected, you could remove the test from that branch.
|
@dasergatskov confirmed that the test as it is currently implemented in this PR would detect the defect in Apple Accelerate: |
This is a very crude attempt to check whether BLAS functions that should return single-precision floating point values actually do that.
Some implementations (like Apple Accelerate) don't do that. See #65.
This is mainly meant for early feedback. (I didn't even check if this compiles.)