Re: [Linaro-TCWG-CI] llvmorg-21-init-6480-g529c5b71c608: 3 regressions 2 improvements on aarch64
Hi,
I'm not familiar with the test suite in question, does it seem related to the test issue addressed in https://github.com/llvm/llvm-project/pull/133128? Or does it seem like it's caused by enabling the slp-vectorizer pass in the O3 pipeline where it was not enabled previously?
________________________________ Von: ci_notify@linaro.org ci_notify@linaro.org Gesendet: Freitag, März 28, 2025 1:21:30 AM An: ohno.yasuyuki@fujitsu.com ohno.yasuyuki@fujitsu.com; itou.tetsuya@fujitsu.com itou.tetsuya@fujitsu.com; t-kawashima@fujitsu.com t-kawashima@fujitsu.com Cc: Kajetan Puchalski Kajetan.Puchalski@arm.com; maxim.kuvyrkov@linaro.org maxim.kuvyrkov@linaro.org Betreff: [Linaro-TCWG-CI] llvmorg-21-init-6480-g529c5b71c608: 3 regressions 2 improvements on aarch64
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In tcwg_flang_test/main-aarch64-O3-neoverse_v1-sve_vla-mpipeliner-stack_arrays, after: | commit llvmorg-21-init-6480-g529c5b71c608 | Author: Kajetan Puchalski kajetan.puchalski@arm.com | Date: Wed Mar 26 16:10:35 2025 +0000 | | [flang] Add -f[no-]slp-vectorize flags (#132801) | | Add -f[no-]slp-vectorize to the flang driver. | Add corresponding -fvectorize-slp to the flang frontend. | | ... 6 lines of the commit log omitted.
Produces 3 regressions 2 improvements: | | regressions.sum: | Running test-suite:Fujitsu/Fortran/0105 ... | NOEXE: test-suite :: Fujitsu/Fortran/0105/Fujitsu-Fortran-0105_0223.test | Running test-suite:Fujitsu/Fortran/0631 ... | FAIL: test-suite :: Fujitsu/Fortran/0631/Fujitsu-Fortran-0631_0051.test | FAIL: test-suite :: Fujitsu/Fortran/0631/Fujitsu-Fortran-0631_0054.test | # "NOEXE" means : the test program cannot be compiled | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one | | improvements.sum: | Running test-suite:Fujitsu/Fortran/0347 ... | FAIL: test-suite :: Fujitsu/Fortran/0347/Fujitsu-Fortran-0347_0083.test | Running test-suite:Fujitsu/Fortran/0675 ... | FAIL: test-suite :: Fujitsu/Fortran/0675/Fujitsu-Fortran-0675_0315.test | # "NOEXE" means : the test program cannot be compiled | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one
Used configuration : * Toolchain : cmake -G Ninja ../llvm/llvm "-DLLVM_ENABLE_PROJECTS=clang;lld;flang;openmp;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=True -DCMAKE_INSTALL_PREFIX=../llvm-install "-DLLVM_TARGETS_TO_BUILD=AArch64" -DCLANG_DEFAULT_LINKER=lld * Testsuite : export LD_LIBRARY_PATH=$\WORKSPACE/llvm-install/lib/aarch64-unknown-linux-gnu${LD_LIBRARY_PATH:+:$\LD_LIBRARY_PATH} cmake -GNinja -DCMAKE_C_COMPILER="$\WORKSPACE/llvm-install/bin/clang" -DCMAKE_CXX_COMPILER="$\WORKSPACE/llvm-install/bin/clang++" -DCMAKE_Fortran_COMPILER="$\WORKSPACE/llvm-install/bin/flang-new" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS= -DCMAKE_Fortran_FLAGS= -DCMAKE_C_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG" -DCMAKE_Fortran_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays" -DTEST_SUITE_FORTRAN=ON -DTEST_SUITE_SUBDIRS=Fujitsu "$\WORKSPACE/test/test-suite"
We track this bug report under https://linaro.atlassian.net/browse/LLVM-1644. Please let us know if you have a fix.
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in * https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v... The full lists of regressions and improvements as well as configure and make commands are in * https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v... The list of [ignored] baseline and flaky failures are in * https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v...
Fujitsu testsuite : https://github.com/fujitsu/compiler-test-suite/
Current build : https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v... Reference build : https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v...
Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/sh...
Full commit : https://github.com/llvm/llvm-project/commit/529c5b71c608c18141432e6fd0ae8924...
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I'm not familiar with the test suite in question, does it seem related to the test issue addressed in https://github.com/llvm/llvm-project/pull/133128? Or does it seem like it's caused by enabling the slp-vectorizer pass in the O3 pipeline where it was not enabled previously?
Thank you for paying attention.
It is caused by enabling the slp-vectorizer pass. Failing tests are the following.
https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0105/0105_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0...
Compiler flags are the following.
flang -O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays
0631_0051.f and 0631_0054.f seem to fail by miscompiling. Output of ot test execution differs form the expected one.
0105_0223.f90 fails by an assertion failure in the backend.
flang: llvm/include/llvm/CodeGen/SlotIndexes.h:626: void llvm::SlotIndexes::insertMBBInMaps(llvm::MachineBasicBlock*): Assertion `unsigned(mbb->getNumber()) == MBBRanges.size() && "Blocks must be added in order"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: bin/flang -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -D NDEBUG -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu neoverse-v1 -target-feature +outline-atomics -target-feature +v8.4a -target-feature +aes -target-feature +bf16 -target-feature +ccdp -target-feature +ccidx -target-feature +ccpp -target-feature +complxnum -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +fullfp16 -target-feature +i8mm -target-feature +jsconv -target-feature +lse -target-feature +neon -target-feature +pauth -target-feature +perfmon -target-feature +rand -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sha2 -target-feature +sha3 -target-feature +sm4 -target-feature +spe -target-feature +ssbs -target-feature +sve -fstack-arrays -vectorize-loops -vectorize-slp -fversion-loops-for-stride -resource-dir lib/clang/21 -mframe-pointer=non-leaf -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -O3 -o /tmp/0105_0223-ecece4.o -x f95-cpp-input Fortran/0105/0105_0223.f90 1. Running pass 'Function Pass Manager' on module 'FIRModule'. 2. Running pass 'Modulo Software Pipelining' on function '@_QQmain' #0 0x0000ffff9245ba28 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (lib/libLLVMSupport.so.21.0git+0x25ba28) #1 0x0000ffff92459110 llvm::sys::RunSignalHandlers() (lib/libLLVMSupport.so.21.0git+0x259110) #2 0x0000ffff92459278 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x0000ffff947307a0 (linux-vdso.so.1+0x7a0) #4 0x0000ffff91e27608 (/lib/aarch64-linux-gnu/libc.so.6+0x87608) #5 0x0000ffff91ddcb3c raise (/lib/aarch64-linux-gnu/libc.so.6+0x3cb3c) #6 0x0000ffff91dc7e00 abort (/lib/aarch64-linux-gnu/libc.so.6+0x27e00) #7 0x0000ffff91dd5cc0 (/lib/aarch64-linux-gnu/libc.so.6+0x35cc0) #8 0x0000ffff91dd5d30 __assert_perror_fail (/lib/aarch64-linux-gnu/libc.so.6+0x35d30) #9 0x0000ffff90da2ccc llvm::SlotIndexes::insertMBBInMaps(llvm::MachineBasicBlock*) MachineBasicBlock.cpp:0:0 #10 0x0000ffff90fa7784 llvm::ModuloScheduleExpander::generateProlog(unsigned int, llvm::MachineBasicBlock*, llvm::DenseMap<llvm::Register, llvm::Register, llvm::DenseMapInfo<llvm::Register, void>, llvm::detail::DenseMapPair<llvm::Register, llvm::Register>>*, llvm::SmallVectorImplllvm::MachineBasicBlock*&) (lib/libLLVMCodeGen.so.21.0git+0x787784) #11 0x0000ffff90fa80d8 llvm::ModuloScheduleExpander::generatePipelinedLoop() (lib/libLLVMCodeGen.so.21.0git+0x7880d8) #12 0x0000ffff90ed96c0 llvm::SwingSchedulerDAG::schedule() (lib/libLLVMCodeGen.so.21.0git+0x6b96c0) #13 0x0000ffff90ed9f94 llvm::MachinePipeliner::swingModuloScheduler(llvm::MachineLoop&) (lib/libLLVMCodeGen.so.21.0git+0x6b9f94) #14 0x0000ffff90eda498 llvm::MachinePipeliner::scheduleLoop(llvm::MachineLoop&) (lib/libLLVMCodeGen.so.21.0git+0x6ba498) #15 0x0000ffff90eda7bc llvm::MachinePipeliner::runOnMachineFunction(llvm::MachineFunction&) (lib/libLLVMCodeGen.so.21.0git+0x6ba7bc) #16 0x0000ffff90e3b1f0 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0 #17 0x0000ffff8f5e48b8 llvm::FPPassManager::runOnFunction(llvm::Function&) (lib/libLLVMCore.so.21.0git+0x4948b8) #18 0x0000ffff8f5e4abc llvm::FPPassManager::runOnModule(llvm::Module&) (lib/libLLVMCore.so.21.0git+0x494abc) #19 0x0000ffff8f5e5720 llvm::legacy::PassManagerImpl::run(llvm::Module&) (lib/libLLVMCore.so.21.0git+0x495720) #20 0x0000ffff930ef0bc Fortran::frontend::CodeGenAction::executeAction() (lib/libflangFrontend.so.21.0git+0x12f0bc) #21 0x0000ffff930d977c Fortran::frontend::FrontendAction::execute() (lib/libflangFrontend.so.21.0git+0x11977c) #22 0x0000ffff9301426c Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) (lib/libflangFrontend.so.21.0git+0x5426c) #23 0x0000ffff93595934 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) (lib/libflangFrontendTool.so.21.0git+0x15934) #24 0x0000aaaadf8259f4 fc1_main(llvm::ArrayRef<char const*>, char const*) (bin/flang+0x159f4) #25 0x0000aaaadf8252f8 main (bin/flang+0x152f8) #26 0x0000ffff91dc84c4 (/lib/aarch64-linux-gnu/libc.so.6+0x284c4) #27 0x0000ffff91dc8598 __libc_start_main (/lib/aarch64-linux-gnu/libc.so.6+0x28598) #28 0x0000aaaadf8236b0 _start (bin/flang+0x136b0)
I don't know where the root cause exists.
Regards, Takahiro Kawashima, Fujitsu
Von: ci_notify@linaro.org ci_notify@linaro.org Gesendet: Freitag, März 28, 2025 1:21:30 AM An: ohno.yasuyuki@fujitsu.com ohno.yasuyuki@fujitsu.com; itou.tetsuya@fujitsu.com itou.tetsuya@fujitsu.com; t-kawashima@fujitsu.com t-kawashima@fujitsu.com Cc: Kajetan Puchalski Kajetan.Puchalski@arm.com; maxim.kuvyrkov@linaro.org maxim.kuvyrkov@linaro.org Betreff: [Linaro-TCWG-CI] llvmorg-21-init-6480-g529c5b71c608: 3 regressions 2 improvements on aarch64
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In tcwg_flang_test/main-aarch64-O3-neoverse_v1-sve_vla-mpipeliner-stack_arrays, after: | commit llvmorg-21-init-6480-g529c5b71c608 | Author: Kajetan Puchalski kajetan.puchalski@arm.com | Date: Wed Mar 26 16:10:35 2025 +0000 | | [flang] Add -f[no-]slp-vectorize flags (#132801) | | Add -f[no-]slp-vectorize to the flang driver. | Add corresponding -fvectorize-slp to the flang frontend. | | ... 6 lines of the commit log omitted.
Produces 3 regressions 2 improvements: | | regressions.sum: | Running test-suite:Fujitsu/Fortran/0105 ... | NOEXE: test-suite :: Fujitsu/Fortran/0105/Fujitsu-Fortran-0105_0223.test | Running test-suite:Fujitsu/Fortran/0631 ... | FAIL: test-suite :: Fujitsu/Fortran/0631/Fujitsu-Fortran-0631_0051.test | FAIL: test-suite :: Fujitsu/Fortran/0631/Fujitsu-Fortran-0631_0054.test | # "NOEXE" means : the test program cannot be compiled | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one | | improvements.sum: | Running test-suite:Fujitsu/Fortran/0347 ... | FAIL: test-suite :: Fujitsu/Fortran/0347/Fujitsu-Fortran-0347_0083.test | Running test-suite:Fujitsu/Fortran/0675 ... | FAIL: test-suite :: Fujitsu/Fortran/0675/Fujitsu-Fortran-0675_0315.test | # "NOEXE" means : the test program cannot be compiled | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one
Used configuration :
- Toolchain : cmake -G Ninja ../llvm/llvm "-DLLVM_ENABLE_PROJECTS=clang;lld;flang;openmp;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=True -DCMAKE_INSTALL_PREFIX=../llvm-install "-DLLVM_TARGETS_TO_BUILD=AArch64" -DCLANG_DEFAULT_LINKER=lld
- Testsuite : export LD_LIBRARY_PATH=$\WORKSPACE/llvm-install/lib/aarch64-unknown-linux-gnu${LD_LIBRARY_PATH:+:$\LD_LIBRARY_PATH}
cmake -GNinja -DCMAKE_C_COMPILER="$\WORKSPACE/llvm-install/bin/clang" -DCMAKE_CXX_COMPILER="$\WORKSPACE/llvm-install/bin/clang++" -DCMAKE_Fortran_COMPILER="$\WORKSPACE/llvm-install/bin/flang-new" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS= -DCMAKE_Fortran_FLAGS= -DCMAKE_C_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG" -DCMAKE_Fortran_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays" -DTEST_SUITE_FORTRAN=ON -DTEST_SUITE_SUBDIRS=Fujitsu "$\WORKSPACE/test/test-suite"
We track this bug report under https://linaro.atlassian.net/browse/LLVM-1644. Please let us know if you have a fix.
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in
The full lists of regressions and improvements as well as configure and make commands are in
The list of [ignored] baseline and flaky failures are in
Fujitsu testsuite : https://github.com/fujitsu/compiler-test-suite/
Current build : https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v... Reference build : https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_v...
Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/sh...
Full commit : https://github.com/llvm/llvm-project/commit/529c5b71c608c18141432e6fd0ae8924...
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
It is caused by enabling the slp-vectorizer pass. Failing tests are the following.
https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0105/0105_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0...
Compiler flags are the following.
flang -O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays
0631_0051.f and 0631_0054.f seem to fail by miscompiling. Output of ot test execution differs form the expected one.
0105_0223.f90 fails by an assertion failure in the backend.
flang: llvm/include/llvm/CodeGen/SlotIndexes.h:626: void llvm::SlotIndexes::insertMBBInMaps(llvm::MachineBasicBlock*): Assertion `unsigned(mbb->getNumber()) == MBBRanges.size() && "Blocks must be added in order"' failed.
Thank you for pointing me in the right direction. I was able to reproduce the issue in my own environment as well. It appears that it's the combination of "-mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg" with "-fslp-vectorize" that is causing problems in this case. Based on my testing:
flang -O3 -mcpu=neoverse-v1 -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -fslp-vectorize 0105_0223.f90 <- broken flang -O3 -mcpu=neoverse-v1 -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -fno-slp-vectorize 0105_0223.f90 <- working flang -O3 -mcpu=neoverse-v1 -fslp-vectorize 0105_0223.f90 <- working flang -O3 -mcpu=neoverse-v1 0105_0223.f90 <- working (same as above, -fslp-vectorize is enabled by O3)
I've not had any prior experience with the two machine pipeliner flags in question, but I'll reach out to some people who should know more and try to determine where the issue is coming from.
Overall I think the consensus in the flang community is that -O3 should behave the same way it does in clang, and since clang enables the slp-vectorizer by default then so should flang. I'm not sure whether an interaction with llvm backend flags such as this one here is reason enough to diverge from that, but I'll start a discussion and get some external opinions on that. I suppose it depends on whether the issue actually originates in the slp-vectorizer or in the pipeliner flags.
In the meantime, would you be able to determine whether the reasons for those flags being passed to your test suite in the first place are already covered by the slp-vectorizer? As in, does omitting "-mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg" actually achieve measurably worse results than leaving those in alongside "-fno-slp-vectorize"? If so then it will be a very useful datapoint for determining what the priority here should be.
Thanks, Kajetan
Hi,
Thank you for investigation.
I have a colleague who is working on the machine pipeliner. I'll ask him.
Regards, Takahiro Kawashima, Fujitsu
It is caused by enabling the slp-vectorizer pass. Failing tests are the following.
https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0105/0105_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0...
Compiler flags are the following.
flang -O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays
0631_0051.f and 0631_0054.f seem to fail by miscompiling. Output of ot test execution differs form the expected one.
0105_0223.f90 fails by an assertion failure in the backend.
flang: llvm/include/llvm/CodeGen/SlotIndexes.h:626: void llvm::SlotIndexes::insertMBBInMaps(llvm::MachineBasicBlock*): Assertion `unsigned(mbb->getNumber()) == MBBRanges.size() && "Blocks must be added in order"' failed.
Thank you for pointing me in the right direction. I was able to reproduce the issue in my own environment as well. It appears that it's the combination of "-mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg" with "-fslp-vectorize" that is causing problems in this case. Based on my testing:
flang -O3 -mcpu=neoverse-v1 -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -fslp-vectorize 0105_0223.f90 <- broken flang -O3 -mcpu=neoverse-v1 -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -fno-slp-vectorize 0105_0223.f90 <- working flang -O3 -mcpu=neoverse-v1 -fslp-vectorize 0105_0223.f90 <- working flang -O3 -mcpu=neoverse-v1 0105_0223.f90 <- working (same as above, -fslp-vectorize is enabled by O3)
I've not had any prior experience with the two machine pipeliner flags in question, but I'll reach out to some people who should know more and try to determine where the issue is coming from.
Overall I think the consensus in the flang community is that -O3 should behave the same way it does in clang, and since clang enables the slp-vectorizer by default then so should flang. I'm not sure whether an interaction with llvm backend flags such as this one here is reason enough to diverge from that, but I'll start a discussion and get some external opinions on that. I suppose it depends on whether the issue actually originates in the slp-vectorizer or in the pipeliner flags.
In the meantime, would you be able to determine whether the reasons for those flags being passed to your test suite in the first place are already covered by the slp-vectorizer? As in, does omitting "-mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg" actually achieve measurably worse results than leaving those in alongside "-fno-slp-vectorize"? If so then it will be a very useful datapoint for determining what the priority here should be.
Thanks, Kajetan
Hi,
I asked my colleagues (@kasuga-fj and @ytmukai). They said these errors seem to be a bug in the MachinePipeliner and they are working on a fix with the community.
You can forget this issue. Thanks.
Best regards, Takahiro Kawashima, Fujitsu
Hi,
Thank you for investigation.
I have a colleague who is working on the machine pipeliner. I'll ask him.
Regards, Takahiro Kawashima, Fujitsu
It is caused by enabling the slp-vectorizer pass. Failing tests are the following.
https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0105/0105_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0... https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0631/0631_0...
Compiler flags are the following.
flang -O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays
0631_0051.f and 0631_0054.f seem to fail by miscompiling. Output of ot test execution differs form the expected one.
0105_0223.f90 fails by an assertion failure in the backend.
flang: llvm/include/llvm/CodeGen/SlotIndexes.h:626: void llvm::SlotIndexes::insertMBBInMaps(llvm::MachineBasicBlock*): Assertion `unsigned(mbb->getNumber()) == MBBRanges.size() && "Blocks must be added in order"' failed.
Thank you for pointing me in the right direction. I was able to reproduce the issue in my own environment as well. It appears that it's the combination of "-mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg" with "-fslp-vectorize" that is causing problems in this case. Based on my testing:
flang -O3 -mcpu=neoverse-v1 -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -fslp-vectorize 0105_0223.f90 <- broken flang -O3 -mcpu=neoverse-v1 -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -fno-slp-vectorize 0105_0223.f90 <- working flang -O3 -mcpu=neoverse-v1 -fslp-vectorize 0105_0223.f90 <- working flang -O3 -mcpu=neoverse-v1 0105_0223.f90 <- working (same as above, -fslp-vectorize is enabled by O3)
I've not had any prior experience with the two machine pipeliner flags in question, but I'll reach out to some people who should know more and try to determine where the issue is coming from.
Overall I think the consensus in the flang community is that -O3 should behave the same way it does in clang, and since clang enables the slp-vectorizer by default then so should flang. I'm not sure whether an interaction with llvm backend flags such as this one here is reason enough to diverge from that, but I'll start a discussion and get some external opinions on that. I suppose it depends on whether the issue actually originates in the slp-vectorizer or in the pipeliner flags.
In the meantime, would you be able to determine whether the reasons for those flags being passed to your test suite in the first place are already covered by the slp-vectorizer? As in, does omitting "-mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg" actually achieve measurably worse results than leaving those in alongside "-fno-slp-vectorize"? If so then it will be a very useful datapoint for determining what the priority here should be.
Thanks, Kajetan
linaro-toolchain@lists.linaro.org
-
Kajetan Puchalski -
Kajetan Puchalski
-
Takahiro Kawashima (Fujitsu)