linux 函数不让编译器优化,GCC编译器优化选项分析及具体优化了什么

本文分析了GCC编译器在不同优化级别(-O0, -O1, -O2, -O3, -Os)下的行为,特别是-O0和-O2的差异。在-O2模式下,编译器执行更多优化,可能导致LCD显示问题。讨论了如-fdefer-pop, -fguess-branch-probability等优化选项的作用,强调了它们对程序性能和代码大小的影响。" 114031728,10535188,Java实现简单打印功能,"['Java开发', '打印功能', '图形绘制', '桌面应用']
摘要由CSDN通过智能技术生成

authorship.gif 

GCC编译器优化选项分析及具体优化了什么

起因:

目前项目使用nios IDE作为开发平台,其使用的编译器为gcc的交叉编译器。在设定编译条件时,在debug模式下生成的程序正常,但是在release模式下会出现LCD显示的开端显示不全,缺少一个字节或字的状况。为了了解具体为什么造成该问题,对两种模式下的配置做了对比,编译器皆为nios2-elf-gcc交叉编译器,debug模式编译器参数为:-DALT_DEBUG-O0-g –Wall。release模式编译器参数为: -DALT_RELEASE -O2 -g –Wall。

两种模式下的参数简单说明如下

-DALT_DEBUG:目前没有明确资料显示该项的具体作用,根据命名可认为与调试有关选项。且两种模式下都有,暂时认为不会造成差异。

-O0: gcc编译器默认优化等级。

-g:gdb调试器支持选项用于在编译时生成相关调试信息。

-Wall:打开所有编译器告警选项,即编译器最严格告警模式。

-O2:gcc编译高于O0低于O3的编译优化选项。

通过对比可以发现两种模式主要的不同在于编译器优化程度不同,那么编译器在两种优化下究竟做了什么优化那?是否由这些问题造成的显示丢失问题那??现在我们来看看gcc编译器的优化参数到底做了什么优化。(注:由于关于nios2-elf-gcc的文档资料十分稀少,不能形成可分析的文档,所以以通用的gcc作为分析,毕竟同出一源)

正文:

GCC编译器优化选项介绍:

GCC编译器在目前是不是用最多的编译器也相去不远,尤其在嵌入式领域很多编译器都是基于GCC的cross gcc版本。毕竟功能成熟而且有开放的源代码。

这里只介绍优化编译的参数

-O用来开启优化编译选项。

-O0:默认模式,不做任何优化。

-O1:优化。该模式下对于一个大的函数或功能会花费更多的时间和内存。

在-O1下:编译会尝试减少代码体积和代码运行时间。但是并不执行会花费大量时间的优化操作。

在该模式下将打开

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值