BLD: Modify cpu detection and printing to get working aarch64 build #11568
Conversation
|
Once the build is working again on aarch64 we could use the new ARMv8-A on Shippable for an altarch CI. |
|
LGTM failure looks unrelated. |
|
Has this been tested to see if it fixes the build? |
numpy/core/src/multiarray/dragon4.c
Outdated
| @@ -2714,7 +2714,7 @@ Dragon4_PrintFloat_Intel_extended128( | |||
| * becomes more common. | |||
| */ | |||
| static npy_uint32 | |||
| Dragon4_PrintFloat_IEEE_binary128( | |||
| Dragon4_PrintFloat_IEEE_binary128_le( | |||
There was a problem hiding this comment.
This function is for quad precision floats, I doubt that ARM implements that.
There was a problem hiding this comment.
Without this change, I got warnings for implicit definition of Dragon4_PrintFloat_IEEE_binary128_le and unused symbol for Dragon4_PrintFloat_IEEE_binary128
Additionally, it failed on import looking for Dragon4_PrintFloat_IEEE_binary128_le
It is very possible that the root cause is actually the identification of what representation it should be using. I've been looking at
numpy/numpy/core/setup_common.py
Line 343 in 20a80e0
I've created the object file outside of running setup_common, and confirmed that the sequence that identifies IEEE_QUAD_LE is indeed present in the od -b dump
There was a problem hiding this comment.
Given the error that was thrown, I tried the naive approach of just editing the function name, not fully expecting it to work, but it did (at least as far as building was concerned, still have some test failures)
There was a problem hiding this comment.
Hmm, LLVM does seem to have software support for quad precision, so I think we need to track this down. What is your compiler tool chain? I'm concerned about the endian part. @ahaldane Comment?
There was a problem hiding this comment.
Maybe wrong flag, but it is there somewhere, https://llvm.org/docs/LangRef.html#floating-point-types. We should be detecting on the byte representation, so either there is an error in that or the compiler is actually producing quad floats.
There was a problem hiding this comment.
OK we need to have two functions, one with the _be extension and one with the _le extension. This function, despite the comment, looks to be big endian with the little endian version in #11570. The difference is only four lines, so it would be nice to have wrappers for the endian specific versions that called into the common code, but the easy fix would be copy the function from # 11570 here with the appropriate name.
There was a problem hiding this comment.
See similar wrappers for the various extended precision alignments.
There was a problem hiding this comment.
I think all the wrappers need to do is swap the a and b members of buf128, so maybe only one wrapper to do that for the _le version and name this function with the _be extension.
There was a problem hiding this comment.
I've pushed the easy fix, cherry-picking the commit from my other PR, I'll work on the wrapper func now
|
The availability of half precision is also interesting. |
|
I have indeed built this on my machine, and @jjhelmus has built it as well on a remote machine |
|
Out of curiosity, what does |
>>> np.finfo(np.float128)
finfo(resolution=1e-33, min=-1.189731495357231765085759326628007e+4932, max=1.189731495357231765085759326628007e+4932, dtype=float128) |
|
OK, looks like genuine IEEE quad precision long doubles, the |
|
Thanks @ksunden . |
|
I think this broke some big-endian systems. |
|
|
Both these functions are used by `Dragon4_PrintFloat_IEEE_binary128`, which was recently made available on big-endian systems without these in numpy#11568.
Both these functions are used by `Dragon4_PrintFloat_IEEE_binary128`, which was recently made available on big-endian systems without these in numpy#11568.
Closes #11564