Defaulting not-yet-implemented ARMv7 softfp functions to their naive C implementations #1216
Conversation
amiasato-zz
changed the title
|
This is not a proper fix. Changes are needed in param.h. Otherwise DGEMM will result in error. Its difficult to explain the changes if you are not familiar with OpenBLAS code. |
|
And it unconditionally degrades raspbian experience.... |
|
@ashwinyes @akira-miasato sorry I honestly did not realize that. |
|
@martin-frbg Since there are lot of issues on ARM softfp, I am working on trying to add softfp support on all ARM assembly files. @xianyi had submitted the support for few single precision APIs but as you know it is not complete. My changes can be found in this branch https://github.com/ashwinyes/OpenBLAS/commits/develop_arm_softfp |
|
arm debian has 3 copies of libc for each capability, nothing removed yet, it will work all ways. |
And this means that all but the already implemented single-precision functions will default to C? If your branch is a proper fix to the issue, I could test it in my case at least. If this is the case, I may close this PR. |
|
You are welcome to test my branch. Most functions (including some of those for which xianyi had added support) fall back to C implementations in that branch. I will be updating the branch as and when I add support to new functions. I will create a PR when eveything is done. If there are any functions which you need at priority, let me know. You may close this PR anyways as there are issues with this PR. |
This temporarily resolves #1215 as discussed in the issue. When compiling with ARM_SOFTFP_ABI=1 for ARMv7, non-single precision OPs will default to their pure C implementations. This is done via Makefile conditions with the aforementioned flag.