fatal error when building the OpenBLAS ThunderX2 and some other dynamic kernels for Windows on ARM #69454
Comments
|
dcopy_k_THUNDERX2T99-ce9e97.zip |
EugeneZelenko
added
backend:AArch64
llvm:asmparser
crash
|
@llvm/issue-subscribers-backend-aarch64 Author: Hernan Martinez (hmartinez82)
I gave it another try on building OpenBLAS with DYNAMIC_ARCH=ON (see https://github.com/msys2/MINGW-packages/blob/b07f75117ed0cfe6e1f000de7caaffb433cb8c80/mingw-w64-openblas/PKGBUILD#L72) for Windows on ARM after patching Clang with https://github.com//pull/67894
Is it possible that I also have to add another patch for supporting the whole fix or this something new related only to ThunderX2?
Clang is still crashing. |
|
Is there something I could do on the OpenBLAS side to help move this along, or some workaround that would allow me to supply a suitable estimate for whatever clang needs to compute the function length here ? The error persists with 19.1 |
|
Turns out that it's actually these cores that are failing to build:
and working with these cores:
Here's a table of working and crashing compiler flags:
|
hmartinez82
changed the title
|
@DavidSpickett @efriedma-quic Do you think you guys can try another look at this? sasum_k_THUNDERX2T99-ee3aec.zip I also got the whole file preprocessed with |
|
@hmartinez82 I'm not sure if your tables are useful in this context - it is most likely not the presence or absence of mtune flags but simply the reuse of originally Thunderx2t99-specific BLAS kernels (with instruction sequences that clang fails to handle) for later cpus |
|
the commonality here seems to be the use of |
|
@martin-frbg That's an awesome finding. I'll create a much simpler Bug report! I can repro this issue with a much simpler code, building with int f(int i) {
int result;
__asm__ (
".align 5 \n"
"add %w0, %w1, #41"
: "=r" (result)
: "r" (i)
:
);
return result;
} |
|
I see now that one of the developer comments on the earlier #66912 (which led to the patch you mentioned in your initial message here) already put that problem down to "there's an alignment in the middle of a function that's keeping us from calculating the length, so stop including alignments for now in code we generate". So it appears to be a known limitation compared to gcc et al., only now it is hand-coded assembly that has the "ugly" instruction so the "don't do that then" approach inside the compiler is of no help |
|
I just need to check what drawbacks the workaround has - I expect the code will still work with the alignments protected by an |
@martin-frbg Yes. If you move the inline assembly to standalone . |
Thanks - not quite what I asked for, however. Guess one needs to wait until #47432 finally gets addressed. |
I gave it another try on building OpenBLAS with DYNAMIC_ARCH=ON (see https://github.com/msys2/MINGW-packages/blob/b07f75117ed0cfe6e1f000de7caaffb433cb8c80/mingw-w64-openblas/PKGBUILD#L72) for Windows on ARM after patching Clang with #67894
Is it possible that I also have to add another patch for supporting the whole fix or this something new related only to ThunderX2?
Clang is still crashing.
The text was updated successfully, but these errors were encountered: