引出问题：

一个好的工程项目代码，特别是开源类的，如果能做到各种优化等级通吃，是一种非常好的工程案例，这样别人借鉴的时候，可以方便的适配到自己工程里。但实际项目中，针对一款产品代码，我们一般不会这么干，因为非常耗精力，意义也不大，一般是追求最高性能，最小代码量或者更高的稳定性，我们会选择一个合理的优化等级。

但是随着工程的复杂，特别是一些第3方组件的加入，很容易碰到不耐优化的情况。也就是这个组件没法适配到我们当前的优化等级里面。甚至有时候我们还会遇到高优化等级能用，改成0级优化反倒不能用了。

本期帖子我们就分享一种方法来解决这个问题，合理的设置不同代码的不同优化等级，即一种优化为主优化等级，其它代码设置到能用的优化等级上，以此来达到通吃的目的。

如果采用这种办法可以一步一步的锁定具体问题所在，并将工程文件全部设置到同一个优化等级是最好的。
?

MDK设置方法（AC5和AC6）：

分两个方向：

1、开启优化后，部分功能不正常

解决思路是把这部分的文件继续设置为低优化等级，整体工程设置为高优化等级（这种方法可以锁定有问题的文件，然后锁定具体有问题的函数）。

2、开启优化后，直接整体卡死

解决思路是整体工程设置为低优化等级，逐步开启工程文件的优化等级。具体到某些函数的优化也是可以单独开启测试的。

AC5设置方法：

比如设置函数优化等级为0
https://www.keil.com/support/man ... hr1359124988971.htm

#pragma push
#pragma O0
void function(void){
    ...                 // Optimized at O0
}
#pragma pop

AC6设置方法：

这里设置无优化

void function(void) _attribute__((optnone))

{
    ...   // Optimized none
}

IAR设置方法：

IAR和MDK的设置是一样的，同样我们也分为两个方向：
?

1、开启优化后，部分功能不正常

解决思路是把这部分的文件继续设置为低优化等级，整体工程设置为高优化等级（这种方法可以锁定有问题的文件，然后锁定具体有问题的函数）。

2、开启优化后，直接整体卡死

这种的解决思路是整体工程设置为低优化等级，逐步开启工程文件的优化等级。具体到某些函数的优化也是可以单独开启测试的。

比如设置函数无优化：
https://netstorage.iar.com/SuppDB/Public/UPDINFO/004916/arm/doc/EWARM_DevelopmentGuide.ENU.pdf （253页）

#pragma optimize=none
void foo(void)
{
    /* Do something, but don't optimize this function */ 
}

GCC设置方法：

GCC的话，我们这里以Embedded Studio为例进行说明，同样我们也分为两个方向：
?

1、开启优化后，部分功能不正常

解决思路是把这部分的文件继续设置为低优化等级，整体工程设置为高优化等级（这种方法可以锁定有问题的文件，然后锁定具体有问题的函数）。

2、开启优化后，直接整体卡死

这种的解决思路是整体工程设置为低优化等级，逐步开启工程文件的优化等级。具体到某些函数的优化也是可以单独开启测试的。

比如设置函数无优化：

#pragma GCC push_options
#pragma GCC optimize ("O0")
void foo(void)
{
    /* Do something, but don't optimize this function */
}
#pragma GCC pop_options

不同优化最容易出问题的地方：

延迟类函数最容易出问题，特别是像for循环这种简单实现的延迟。可以考虑使用DWT时钟周期计数器做延迟。

http://www.armbbs.cn/forum.php?mod=viewthread&tid=89128

?

不迷信编译器：

即使再强劲的编译器，有触摸不到的天花板。

MDK AC6的0级优化在这方面的设计问题最明显。比如MDK AC6.14使用0级优化编译HAL库的n级条件表达式会产生巨大的栈需求。

现象：

使用MDK5.30 AC6.14的0级优化测试RTX5的模板程序，发现启动任务需要高达2000字节的栈需求。

原因分析：

通过不断的调试和查看map，htm等文件，最终锁定是H7的HAL库函数UART_SetConfig导致的。

?

进一步的排查，锁定是下面这种n级条件表示导致的，下面这种类型的表达式偏偏在函数UART_SetConfig里面有一大批，导致产生巨大的栈需求。

/** @brief  Get UART clok division factor from clock prescaler value.
  * @param  __CLOCKPRESCALER__ UART prescaler value.
  * @retval UART clock division factor
  */
#define UART_GET_DIV_FACTOR(__CLOCKPRESCALER__) \
  (((__CLOCKPRESCALER__) == UART_PRESCALER_DIV1)   ? 1U :       \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV2)   ? 2U :       \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV4)   ? 4U :       \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV6)   ? 6U :       \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV8)   ? 8U :       \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV10)  ? 10U :      \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV12)  ? 12U :      \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV16)  ? 16U :      \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV32)  ? 32U :      \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV64)  ? 64U :      \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV128) ? 128U :     \
   ((__CLOCKPRESCALER__) == UART_PRESCALER_DIV256) ? 256U : 1U)

解决办法：

使用AC6中0以外的其它优化就解决了，或者使用AC5的任何优化等级也都可以解决。

又比如：
如果用AC6的优化等级0，没有选择使用微库的话（底层做了C标准库重定向），偶尔会造成脱机（调试仿真下可以使用，拔掉下载器运行就失败）执行失败，将微库勾上即可解决：

这坑也非常容易遇到。