OpenBLAS在LoongArch64架构下使用Clang/Flang编译问题解析

背景介绍

OpenBLAS作为一款高性能的开源BLAS实现，支持多种处理器架构和编译器。近期在LoongArch64架构（龙芯3A6000处理器）上使用Clang/Flang编译器组合进行编译时，开发者遇到了两个主要的技术问题。本文将详细分析这些问题及其解决方案。

问题一：汇编语法兼容性问题

当使用Clang编译LoongArch64架构的汇编代码时，出现了语法解析错误。具体表现为在.end指令后跟随其他内容时，Clang的汇编器无法正确解析。

技术分析

在common_loongarch64.h头文件中，原有的宏定义将.end指令与GNUSTACK标记写在同一行，这种语法格式在GNU汇编器中是被允许的，但Clang的汇编器对此有更严格的语法要求。

解决方案

通过添加编译器判断条件，针对Clang使用简化的.end指令定义，而对其他编译器保持原有语法：

#ifdef __clang__
#define EPILOGUE .end
#else
#define EPILOGUE      \
    .end    REALNAME ;\
    GNUSTACK
#endif

这种修改既保证了Clang下的正常编译，又不影响其他编译器下的原有功能。

问题二：Flang编译器参数兼容性问题

使用Flang（LLVM的Fortran前端）编译时，遇到了-mabi=lp64d参数不被识别的问题。

技术分析

Flang作为LLVM项目的一部分，其命令行参数与传统的GNU Fortran编译器有所不同。-mabi参数是GCC特有的架构ABI指定参数，而Flang并不支持这一参数。

解决方案

在构建系统中添加对Flang编译器的特殊处理，避免向其传递不支持的参数：

1. Makefile构建系统：在Makefile.system中添加对-mabi参数的过滤
2. CMake构建系统：在cmake/fc.cmake中添加对LLVMFlang的条件判断

更深层次的Fortran编译问题

在解决上述问题后，编译过程中仍遇到了Fortran源文件（如slacon.f）的编译失败。这实际上是LLVM 18/19版本中的一个代码生成器缺陷，已在LLVM 20中得到修复。

技术建议

对于LoongArch64架构上的OpenBLAS构建，建议：

1. 使用LLVM 20或更高版本的工具链
2. 或者暂时使用GNU工具链（GCC+Gfortran）作为替代方案

总结

通过本文的分析和解决方案，开发者可以在LoongArch64架构上成功使用Clang/Flang工具链构建OpenBLAS。这为在该架构上使用LLVM生态提供了更多可能性，也为其他开源项目在LoongArch64上的适配提供了参考经验。

随着LoongArch生态的不断成熟和LLVM对LoongArch支持的完善，未来这类兼容性问题将会逐渐减少，为开发者提供更顺畅的跨平台开发体验。