工程在调试配置下运行正常，换成优化版本后，等待循环不再退出，或者计算结果发生变化，这时不能仅凭“关闭优化就恢复”判断编译器出了问题。优化会改变指令安排、变量保存位置和执行时间，也可能暴露原先被掩盖的代码错误。Green Hills MULTI提供了面向调试、通用、体积和速度的优化策略。选择哪一种，需要结合工程目标；结果出现差异时，则要找到具体从哪里开始不同。

　　一、Green Hills怎么配置编译器优化级别

　　Green Hills的优化策略有各自的用途，并非简单地逐级增强。以下按MULTI英文界面说明，选项以所用处理器和编译器版本为准。

　　1、选择合适的优化策略

　　新工程还在核对功能时，保留清楚的调试过程更方便；准备评估性能时，再逐步切换策略，结果也更容易比较。

　　①打开目标程序的构建选项，进入【Optimization】→【Optimization Strategy】。

　　②需要兼顾调试与一定优化时，选择【Optimize for Debuggability】，对应-Odebug。

　　③代码体积与执行速度都需要考虑时，选择【Optimize for General Use】，对应-Ogeneral；存储空间紧张时，可以评估【Optimize for Size】，对应-Osize。

　　④对已经测出耗时较多的模块，评估【Optimize for Speed】，对应-Ospeed，并观察代码体积是否增加。

　　⑤建立关闭优化的对照版本时，选择【No Optimizations】，对应-Onone。它与专门禁止内联的调试策略仍有区别。

　　2、确认选项实际作用的范围

　　①查看选中的工程节点，确认正在修改整个程序还是某个源文件的选项。

　　②检查可疑文件是否有单独设置，避免项目级选项已经改变，文件仍沿用自己的优化策略。

　　③保存后重新构建，从编译日志核对相关源文件使用的参数，再加载本次生成的程序。

　　只看配置名称还不够。名为Debug的工程也可能启用了优化，名为Release的工程也可能保留了局部调试设置，实际编译参数更能说明情况。

　　二、Green Hills优化后程序运行结果发生变化如何检查

　　先把差异变成能够重复观察的现象。例如记录输入相同的两次运算在哪个输出开始不同，比笼统地描述“优化后不正常”更容易定位。

　　1、分清运行错误与调试显示变化

　　①给两个版本提供相同输入，在函数边界或任务完成位置记录输出，确认实际结果是否不同。

　　②遇到单步跳行、局部变量无法查看等情况，结合反汇编观察对应指令，不要只根据源码光标判断执行过程。

　　③检查断点是否改变了中断响应或外设时序，必要时减少停机观察，改用少量记录获取结果。

　　优化后，部分变量可能不再独立保存在内存中，一行源码也未必对应一段连续指令。调试显示难以理解，与程序算错是两回事。

　　2、等待循环异常，检查外部修改的数据

　　主程序等待一个标志，中断负责修改它，这类代码对变量声明和同步方式有明确要求。

　　①找到循环读取的标志，确认它是否会被中断、外设或其他执行单元改变。

　　②检查相关声明是否符合volatile等访问要求，并查看生成的指令是否仍在循环中读取目标地址。

　　③对内存映射寄存器，沿用芯片支持包提供的寄存器定义，核对访问宽度和地址。

　　④对任务间共享数据，继续检查原子操作、临界区或同步机制；涉及DMA时，还要考虑缓存一致性。

　　3、数值突然异常，先查代码边界

　　①处理构建警告，追查未初始化读取、函数声明不一致及可疑类型转换。

　　②检查数组下标、指针有效期、有符号整数溢出和移位范围。

　　③如果通过不同类型的指针读写同一块数据，核对是否违反类型别名规则，必要时改用符合语言规则的数据复制方式。

　　④修正后恢复原优化策略，再使用相同输入验证。

　　这些错误在未优化版本中也可能存在，只是当时的寄存器分配或内存布局没有让问题显现。增加一次打印后故障消失，也不能证明代码已经正确。

　　4、浮点结果有差异，对照运算选项

　　浮点运算存在舍入误差。计算顺序改变、使用融合乘加或替换数学函数，都可能影响结果，误差是否可以接受则取决于应用要求。

　　①记录差异的数量级，区分末尾小数变化、判断分支改变，以及异常值等情况。

　　②对比两个配置中的【Floating Point Associativity】和其他浮点选项，确认是否允许调整表达式的结合顺序。

　　③检查快速浮点设置、融合乘加及数学函数替换是否发生变化，逐项对照测试。

　　④用边界输入和接近判断阈值的输入复测，不能只看一组普通数据。

　　5、外设或通信异常，测量实际时序

　　①查找依靠空循环或固定指令数量实现的延时，测量优化前后的持续时间。

　　②对有明确时间要求的操作，使用硬件定时器等适合的计时方式，避免把源码循环次数当作时间保证。

　　③观察中断、任务切换与共享缓冲区的读写顺序，检查速度变化后是否暴露竞争问题。

　　三、Green Hills优化参数怎么逐步确定

　　整个工程关闭优化，适合用来判断问题是否与构建策略有关。继续缩小范围，才能知道该修改代码，还是调整某个模块的选项。

　　1、把差异缩小到具体文件

　　①保留能够复现问题的优化配置，只对一部分可疑源文件改用调试策略。

　　②如果现象恢复，继续缩小这部分文件的范围；没有变化，则检查其他模块。

　　③找到相关函数后，对照输入、输出和生成指令，追查差异出现的位置。

　　局部降低优化可以作为排查手段。若暂时需要保留这一设置，应记录涉及文件、复现条件和原因，方便后续维护。

　　2、用项目指标决定是否保留优化

　　①对运行稳定的版本测量执行时间、代码体积及必要的栈使用情况，保留比较结果。

　　②使用最终准备交付的构建配置完成回归测试，覆盖中断、通信和边界输入。

　　③将通过验证的选项纳入工程配置管理，避免只保留在某台电脑的临时设置中。

　　总结

　　Green Hills提供多种优化策略，给嵌入式工程留出了调试、速度与存储空间之间的选择余地。项目不必统一追求更强的优化，耗时模块和普通业务代码可以有不同安排。对维护人员来说，了解选项实际影响了什么，也比记住一个级别名称更有用。希望以上内容能帮助大家在结果发生变化时找到检查方向，逐步确定适合自己工程的配置，少一些凭现象反复试改。如果有相关需求，欢迎联系我们咨询。