Re: [patch][rfc] Enabling more optimizations with -ON

[Mike Frysinger <vapier at gentoo dot org>]

On 19 Nov 2014 18:13, Rafael EspÃndola wrote:
> On 19 November 2014 18:07, Mike Frysinger wrote:
> > On 03 Nov 2014 11:39, Rafael EspÃndola wrote:
> >> In compilers the -ON options enable various optimizations. Different
> >> compilers (and compiler versions) have different ones, but the option
> >> itself is commonly available and selects a somewhat corresponding
> >> level.
> >>
> >> In both bfd ld and gold very few optimizations are enabled with the
> >> -ON options. This means that users have to know which optimizations
> >> are available:
> >>
> >> ld ...-O3 --gc-sections --icf=safe....
> >>
> >> If an optimization is added to one of them, a configure check has to
> >> be used to find if the program is being linked with gold or bfd (and
> >> which version).
> >>
> >> As a starting point, the attached patch changes gold to gc sections by
> >> default if given -O3 or higher. It can still be disabled with an
> >> explicit --no-gc-sections.
> >
> > i don't think this is really useful.  gc-sections requires code to be compiled
> > with -f{data,function}-sections in order to be effective.  so at that point, the
> > user is opting in to the desired behavior ...
> 
> This particular example is bit of a chicken and egg issue with the
> compiler. There was some discussion at least on the clang side to
> enable ffunction-sections and fdata-sections by default.

these options are not free ... the tradeoff you get with garbage collecting 
unused sections is paid with some alignment bloat in between sections

> The more general question is "should the liker do more optimizations
> at -Ox"? It is very convenient since then the user doesn't need to
> know the set of optimizations available for a given linker.

adding generally useful optimizations makes sense i think, but i'm not sure 
gc-sections falls into that bucket.  the linker should be conservative.

> For example, right now a project needs a configure/cmake check to find
> out if it is being linked with gold before using -icf=safe, but if it
> was enabled with some -O level, it could just pass that -O option to
> both gold and bfd.

i'm not sure this is a good solution to the general problem.  plus, a portable 
package would still have to do linker flag probing to make sure it's safe.
-mike

Attachment: signature.asc
Description: Digital signature