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

问题背景

在LoongArch64架构（龙芯3A6000处理器）上使用Clang/Flang编译器构建OpenBLAS时，开发人员遇到了两类主要编译问题。这些问题涉及GNU汇编语法兼容性和Fortran编译器参数处理，影响了项目的正常编译流程。

核心问题分析

1. 汇编语法兼容性问题

当使用Clang编译时，系统报告了GNU汇编语法错误：

../kernel/loongarch64/amax_lasx.S:232:10: error: expected newline
    .end samax_k ; .section .note.GNU-stack,"",@progbits

根本原因在于Clang的汇编器对GNU汇编语法的处理与GCC存在差异。具体表现为：

• Clang不接受在同一行混合使用.end指令和.section指令
• 需要显式分行编写这些汇编指令

2. Flang编译器参数问题

使用Flang-new编译器时出现参数识别错误：

flang-new: error: unknown argument: '-mabi=lp64d'

这是由于Flang编译器前端不支持传统的GCC风格架构参数传递方式，特别是-mabi=这类参数在Flang中不被识别。

解决方案

针对汇编语法问题

修改common_loongarch64.h文件中的宏定义，为Clang编译器提供特殊处理：

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

这一修改确保：

• 使用Clang时仅生成简单的.end指令
• 其他编译器仍保持原有的多指令格式
• 兼容性得到保证的同时不影响功能

针对Flang参数问题

需要从两个层面解决：

1. Makefile构建系统： 在Makefile.system中过滤掉Flang不支持的-mabi参数：

FCOMMON_OPT += $(filter-out -mabi=%,$(FCOMMON_OPT))

2. CMake构建系统： 修改cmake/fc.cmake文件，增加Flang编译器判断：

if(NOT CMAKE_Fortran_COMPILER_ID MATCHES "LLVMFlang.*")
    # 原有参数设置逻辑
endif()

更深层次的技术考量

1. ABI兼容性：LoongArch64架构支持多种ABI模式，但Flang作为新兴编译器，其参数传递机制与传统GCC工具链存在差异，需要特殊处理。

2. 安全考虑：原始代码中的GNUSTACK标记用于设置栈不可执行属性(NX bit)，在修改时需要评估不同链接器下的安全性影响。

3. 编译器生态：随着LLVM工具链的普及，开源项目需要同时考虑GCC和LLVM两大工具链的兼容性问题。

验证与测试

解决方案已在以下环境中验证通过：

• 硬件平台：龙芯3A6000处理器
• 操作系统：Debian sid/AOSC OS
• 工具链版本：
  • Clang 18.1.8/19.1.0/20.1.2
  • Flang-new对应版本
  • CMake 3.30.3/3.31.6

总结

OpenBLAS在LoongArch64架构上的构建问题反映了新兴硬件平台与多编译器支持带来的挑战。通过针对性的代码修改和构建系统调整，成功解决了Clang/Flang下的编译问题。这类问题的解决模式也为其他开源项目在LoongArch架构上的适配提供了参考：

1. 注意汇编语法的编译器差异
2. 处理新兴编译器的参数特殊性
3. 保持对传统工具链的兼容性
4. 考虑平台特定的安全需求

随着LoongArch生态的不断完善和LLVM工具链的持续发展，这类跨工具链的兼容性问题将逐渐减少，但目前阶段仍需要开发者保持关注并做好适配工作。