Config.in: change default optimization level from -Os to -O2

Historically, Buildroot has defaulted to -Os as the gcc optimization
flags. However, this default is probably not the most appropriate
anymore, and this commit therefore changes the default to -O2.

Here are some arguments in favor of this change:

- Most Buildroot uses use Buildroot for platforms that have a
  reasonable amount of storage, and the difference between -Os and -O2
  in terms of code size is no longer than significant compared to the
  size of storage typically available on average embedded Linux
  devices

- -Os can have a pretty bad performance impact, compared to -O2.

- -Os is much less widely tested than -O2. For example, with recent
   versions of gcc, there are parts of Qt5 that segfault when compiled
   with -Os and work perfectly fine with -O2. Yes, it's a compiler bug
   that should be fixed, but in the mean time, having a default that's
   more widely used/tested makes sense.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 Config.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Thomas, All,

On 2023-12-27 17:58 +0100, Thomas Petazzoni via buildroot spake thusly:
> Historically, Buildroot has defaulted to -Os as the gcc optimization
> flags. However, this default is probably not the most appropriate
> anymore, and this commit therefore changes the default to -O2.
> 
> Here are some arguments in favor of this change:
> 
> - Most Buildroot uses use Buildroot for platforms that have a

s/uses/users/ maybe?

>   reasonable amount of storage, and the difference between -Os and -O2
>   in terms of code size is no longer than significant compared to the

s/than/as/

>   size of storage typically available on average embedded Linux
>   devices

... nowadays.

> - -Os can have a pretty bad performance impact, compared to -O2.

What impact are we speaking of? Basically, -Os is -O2 except for
optimisations that increase code size. Also, smaller code fit better
in caches, so there can be a speed gain to have smaller code too.

So, stating that -Os has a "pretty bad" performance impact is not that
obvious.

But otherwise, I agree that, -Os does not bring much size gain, compared
to storage of devices nowadays, so, except for those little nits:

Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> - -Os is much less widely tested than -O2. For example, with recent
>    versions of gcc, there are parts of Qt5 that segfault when compiled
>    with -Os and work perfectly fine with -O2. Yes, it's a compiler bug
>    that should be fixed, but in the mean time, having a default that's
>    more widely used/tested makes sense.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> ---
>  Config.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.in b/Config.in
> index 554b4062eb..c38b1e6454 100644
> --- a/Config.in
> +++ b/Config.in
> @@ -474,7 +474,7 @@ config BR2_STRIP_EXCLUDE_DIRS
>  
>  choice
>  	prompt "gcc optimization level"
> -	default BR2_OPTIMIZE_S
> +	default BR2_OPTIMIZE_2
>  	help
>  	  Set the optimization level for gcc
>  
> -- 
> 2.43.0
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

Hello,

Thanks for the feedback.

On Wed, 27 Dec 2023 18:32:53 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> > Here are some arguments in favor of this change:
> > 
> > - Most Buildroot uses use Buildroot for platforms that have a  
> 
> s/uses/users/ maybe?
> 
> >   reasonable amount of storage, and the difference between -Os and -O2
> >   in terms of code size is no longer than significant compared to the  
> 
> s/than/as/
> 
> >   size of storage typically available on average embedded Linux
> >   devices  
> 
> ... nowadays.

I sent a v2 (where I messed up) and then a v3, fixing those. I actually
made another change: the Config.in help text of BR2_OPTIMIZE_S
explicitly mentioned that it was the default. So I updated this and
moved the text to BR2_OPTIMIZE_2.

> 
> > - -Os can have a pretty bad performance impact, compared to -O2.  
> 
> What impact are we speaking of? Basically, -Os is -O2 except for
> optimisations that increase code size. Also, smaller code fit better
> in caches, so there can be a speed gain to have smaller code too.
> 
> So, stating that -Os has a "pretty bad" performance impact is not that
> obvious.

I obviously don't have hard numbers, but I definitely remember
getting reports of performance problems that got solved by moving to
-O2. However, I honestly don't remember if it was a bug report in our
public bug tracker, or an issue in a customer project. But I had in my
TODO-list for a long time to send this patch, because on multiple
occasions I saw people being hit by issues being caused by the default
setting of -Os.

> Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>

Thanks, the v3 has your Acked-by :-)

Best regards,

Thomas