[pacman-dev] LTO and PGO build options

[Allan McRae]

On 20/03/16 19:03, Que Quotion wrote:
>> What is the advantage to all this beyond people adding "-flto" to their
> CFLAGS if they want LTO?
> 
> The advantage is not having to do that. Theoretically, the compiler
> devs expect LTO to always work and want reports when it does not. We
> should be able to enable LTO for every build, but my experience is
> that--occasionally--the linker fails.
> 
> Users so inclined could "set it and forget it" most of the time, and
> occasionally disable it if a package does not build. I find this more
> efficient than modifying the PKGBUILD of each package that could
> benefit from LTO.
> 

Adding -flto to CFLAGS and forgetting also is fine.  Remove it when the
software is broken with LTO.

>> All modern builds should handle the rest by themselves.
> 
> Should, but don't last time I checked. A number of builds failed for
> not having {AR,RANLIB,NM}FLAGS set when attempting LTO. I see the
> complexity as another reason to have this built into makepkg instead
> of having to do all this tediousness on a per-package basis.
> 
> The less anyone has to edit PKGBUILDs for generic things like
> optimization, the better I think.

Add -flto to CFLAGS, report broken software upstream.  I am not adding
this to makepkg.

>> I'm guessing this is untested...
> 
> That's kinda like.. not testing it, yeah?
> 
> I've been using this for quite some time. Nearly everything compiles
> successfully with pgo. There were a couple of wrapper leftovers to fix
> in my initial post, see below. The problem with only me doing the
> testing is no one will ever beleive my success. I have been
> successful, believe it--or try it for yourself.

I was talking about the patch you provided being untested.  You appear
to have understood that as you have fixed it....

>> Anyway, I don't think PGO has a place in makepkg itself
> 
> Why not, specifically? We have other cflag stuff in there; besides, it
> should be disabled by default so users could opt-in when they feel
> ready. Do you know you can PGO just about any package in the
> repositories? It's still takes two build steps, but this macro saves a
> lot of tediousness over editing the individual PKGBUILDS. I don't see
> how it's any more or less worthy than ccache, upx, etc.
> 

upx is dropped. optipng is dropped.

I am not adding an option to makepkg that does non-deterministic
optimisation.

A