ARC GNU工具链2024.06版本验证问题深度分析

ARC GNU工具链2024.06版本验证问题深度分析

概述

近期对ARC GNU工具链2024.06版本进行的验证测试中，发现了多个关键问题，这些问题主要集中在编译器选项冲突、模拟器配置不当以及指令集兼容性等方面。本文将对这些技术问题进行深入剖析，并探讨其背后的根本原因。

主要问题分析

1. 编译器选项冲突问题

在测试过程中，最突出的问题是"-mcpu"选项的多重指定冲突。测试框架默认会添加"-mcpu=archs"选项，而部分测试用例又通过dg指令显式指定了不同的"-mcpu"值（如"-mcpu=em"），导致编译器报出"multiple '-mcpu=' options specified"警告并引发测试失败。

这个问题影响了20多个测试用例，包括：

• 位移操作测试（ashrsi、lshrsi、shlsi系列）
• 特殊指令测试（extvsi、swap等）
• 条件码测试（scc-ltu.c）

技术细节：ARC架构支持多种处理器变体，每种变体可能有不同的指令集扩展和优化策略。当编译器接收到冲突的-mcpu选项时，无法确定应该为哪种处理器生成代码，从而导致不可预测的行为。

2. 模拟器退出码处理问题

测试框架使用nsim.specs作为模拟器配置时，无法正确处理程序的退出码，导致59个测试用例失败。具体表现为模拟器返回了非标准的退出码4242，而测试框架期望的是标准的POSIX退出码。

解决方案：改用MetaWare Hostlink（hl.specs）可以解决此问题，通过设置环境变量ARC_NSIM_HOSTLINK=metaware即可实现切换。

3. 指令异常问题

在hs38_linux配置下运行c23-stdarg-9.c测试时，模拟器报告了指令异常。深入分析发现，问题出在dmpywh指令被错误地放置在延迟槽中，且使用了奇数寄存器r13作为64位操作的目标寄存器。

架构规范：根据ARCv2处理器参考手册，所有产生64位结果的操作，其A操作数必须是偶数编号的寄存器。编译器在此处违反了这一约束条件。

复现方法：

1. 使用-O2优化级别编译测试用例
2. 在模拟器中启用完整指令追踪
3. 配置模拟器支持dmpywh指令（-p nsim_isa_mpy_option=9）

问题根源与解决方案

编译器选项冲突的解决思路

正确的做法是让每个非通用测试用例自行检查是否支持当前运行配置。可以参考ARM工具链中的做法，使用dg-skip-if指令来跳过不支持的配置，例如：

/* { dg-skip-if "skip for this target" { arc-*-* } { "-mcpu=archs" } { "" } } */

指令异常问题的深层分析

通过简化测试用例，我们发现该问题与stdarg.h中可变参数处理相关。编译器在优化过程中，错误地将dmpywh指令（双字乘法）放置在分支延迟槽中，并使用了不合适的寄存器分配。

临时解决方案：使用-fno-delayed-branch选项可以避免指令被放入延迟槽，但这会影响性能优化。

长期解决方案：需要修改编译器的寄存器分配策略，确保64位操作使用偶数寄存器对，并改进延迟槽填充算法，避免将复杂指令放入延迟槽。

验证改进建议

1. 测试用例规范化：所有特定于某处理器变体的测试用例都应包含适当的dg-skip-if指令，明确声明其支持和不支持的配置。

2. 模拟器配置标准化：统一使用MetaWare Hostlink作为默认配置，确保退出码处理的可靠性。

3. 编译器测试增强：增加对64位操作寄存器配对的静态检查，防止类似dmpywh问题的发生。

4. 持续集成改进：在CI流程中加入配置冲突检测，提前发现选项不兼容问题。

结论

本次2024.06版本验证发现的问题反映了工具链开发中的几个关键挑战：配置管理、模拟器集成和指令集正确性。通过这些问题分析，我们可以改进开发流程，提高未来版本的稳定性。特别是需要加强：

• 测试用例的规范化管理
• 编译器后端对架构约束的严格遵守
• 工具链各组件间的集成测试

这些改进将有助于提升ARC GNU工具链的整体质量和可靠性，为开发者提供更稳定的开发环境。