TASKING TriCore编译器提供多级代码优化，可以在代码体积、执行速度和调试便利性之间做取舍。优化打开后，编译器可能合并表达式、内联函数、删除未使用变量，或者改变变量的存储位置，因此调试时会出现局部变量无法显示、数值跳变、断点与源码行对应不上等情况。遇到这类问题时，应先确认工程实际使用的优化等级，再检查调试信息是否正常生成。

　　一、TASKING怎么设置代码优化级别

　　TASKING可以在工程配置中直接选择预设优化等级，也可以切换到Custom optimization单独控制某些优化动作。调试阶段可以先使用Level 1，不必一开始就把所有优化关闭。

　　1、设置工程优化级别

　　①选中工程，进入【Project】→【Properties】。

　　②展开【C/C++Build】，打开【Settings】。

　　③在【Configuration】中选择当前使用的【Debug】【Release】或【All configurations】。

　　④进入【C/C++Compiler】→【Optimization】。

　　⑤在【Optimization level】中选择需要的等级。

　　⑥【Level 0-No optimization】适合需要尽量按照源码顺序单步检查的场景。

　　⑦【Level 1-Optimize】会保留较好的调试能力，Level 2下调试异常时可以先切换到这一档。

　　⑧【Level 2-Optimize more】是编译器默认优化级别。

　　⑨【Level 3-Optimize most】会启用更多优化，源码与最终指令的对应关系可能发生较大变化。

　　⑩点击【Apply】保存后重新执行完整Build。

　　2、单独调整具体优化项目

　　①进入【C/C++Compiler】→【Optimization】。

　　②把【Optimization level】切换为【Custom optimization】。

　　③打开对应的Custom optimization设置。

　　④函数调用位置变化明显时，检查【Automatic function inlining】。

　　⑤执行路径变化时，检查【Control flow simplification】。

　　⑥表达式被合并时，检查【Common subexpression elimination】和【Expression simplification】。

　　⑦循环代码不好单步时，检查【Loop transformations】。

　　⑧一次只调整少量项目，重新Build后做对照测试。

　　如果问题只出现在一个模块，也可以只降低目标源文件的优化，不必长期修改整个工程。

　　3、调整速度和代码体积取舍

　　①保持在【C/C++Compiler】→【Optimization】。

　　②找到【Trade-off between speed and size】。

　　③偏向执行速度时选择较低的Trade-off值。

　　④偏向代码体积时选择较高的值。

　　⑤修改后重新生成工程。

　　⑥查看Map文件中的代码尺寸。

　　⑦再测试关键函数执行时间。

　　Trade-off主要影响编译器在速度和体积之间的选择，并不会代替Optimization level。排查变量显示问题时，先处理优化等级更直接。

　　二、TASKING开启优化后调试变量显示异常如何处理

　　优化后的局部变量不一定始终对应固定RAM地址，它可能暂存在寄存器中，也可能在某段代码执行完以后被直接删除。因此Watch窗口显示不可用，并不能直接判断程序数据已经损坏。

　　1、先检查Symbolic Debug Information

　　①进入【Project】→【Properties】→【C/C++Build】→【Settings】。

　　②打开【C/C++Compiler】→【Debugging】。

　　③找到【Generate symbolic debug information】。

　　④调试配置可以选择【Default】。

　　⑤当前设置为【None】时，改成【Default】并重新编译。

　　⑥需要更多DWARF调试信息时，可以切换到【Full】做一次对照。

　　⑦重新启动调试器，打开Locals和Watch窗口。

　　⑧在变量真正参与计算的位置重新设置断点。

　　【Full】会增加调试信息，但已经被编译器删除的变量不会因此重新出现，所以变量仍无法观察时还要继续检查优化等级。

　　2、变量显示Unavailable时降低优化等级

　　①记录当前【Optimization level】。

　　②当前为【Level 2】或【Level 3】时，先切换到【Level 1】。

　　③执行完整Rebuild。

　　④在变量赋值和使用位置重新设置断点。

　　⑤同时查看Locals、Watch和寄存器中的数据。

　　⑥Level 1下仍难以判断时，再暂时切换到【Level 0】。

　　⑦重新测试同一段程序。

　　⑧如果关闭优化后变量恢复正常显示，可以把问题先归到优化后的调试信息变化，再决定是否继续缩小优化范围。

　　3、单步顺序和断点位置异常时检查汇编

　　①进入调试器打开【Disassembly】。

　　②查看当前【PC】对应的指令。

　　③对照源码检查实际执行位置。

　　④源码某一行没有对应指令时，检查该表达式是否已经被合并或删除。

　　⑤函数无法按源码顺序进入时，检查Inlining。

　　⑥切换到【Level 1】重新编译并再次对照。

　　⑦不要只根据源码当前高亮行判断变量是否已经完成赋值。

　　三、程序只在开启优化后异常怎么继续排查

　　如果不只是调试窗口显示异常，而是程序在Level 0运行正常、切换到Level 2或Level 3后才出现结果错误，就要继续检查源码本身。此时重点是共享数据、异步访问和不同优化阶段暴露出的代码问题。

　　1、检查共享变量和volatile使用

　　①找到优化后数值异常的变量。

　　②确认它是否会被中断、DMA、其他CPU核心或硬件寄存器异步修改。

　　③这类数据需要每次真实访问内存时，检查源码是否按用途使用【volatile】。

　　④多核工程还要确认共享变量放在各核心都能访问的内存区域。

　　⑤重新编译并复现异常路径。

　　⑥不要为了让Watch窗口持续显示，就给普通局部变量统一增加volatile。

　　2、逐级定位触发异常的优化动作

　　①先使用【Level 0】确认程序状态。

　　②切换到【Level 1】重新测试。

　　③再切换到【Level 2】。

　　④确定异常从哪一级开始后，进入【Custom optimization】。

　　⑤逐项调整该级别启用的优化动作。

　　⑥每次修改后重新编译目标模块。

　　⑦找到相关优化后，再检查对应源码中的指针访问、未初始化变量、表达式和数据同步。

　　总结

　　TASKING开启代码优化后，调试变量和源码执行位置发生变化属于常见现象，可以先用Level 1和Default调试信息做对照，尽量保留接近目标版本的运行条件。如果程序结果本身也随优化等级变化，则应继续检查共享数据、指针访问和源码行为，而不能只处理调试器中的变量显示。如需进一步了解TASKING代码优化配置、调试信息设置与优化后变量异常排查方法，欢迎联系咨询。