User:Aslantis/Lesser known optimization flags for make.conf

From Gentoo Wiki
Jump to:navigation Jump to:search
You've heard it before, you'll hear it again: aggressive optimization flags can cause build and runtime errors. You have been warned.
Don't just copy and paste anything from this page without understanding what you're doing! :D

This is my list of certain optimization flags you can set in your make.conf. I decided to start this after learning about optimization flags that I didn't know you could set for rust, and got curious about other possibilities so decided to start a running list!!

If you know any other flags you can set for further optimizations, I'd appreciate if you added them to this page!! (or at least let me know about them in my talk page.)

I have specific info about each variable/language at the bottom. I have the sane optimization levels uncommented, and if applicable the most "aggressive" optimizations commented out directly below. Please read the warnings at the bottom about these "aggressive" optimizations, and please reproduce bugs without these flags before reporting.

FILE portage/make.conf
## Common flags for C, C++, Fortran 77, and Fortran 9x respectively
COMMON_FLAGS="-O3 -pipe -march=native -flto" #Note that -O3 can sometimes compile _slower_ binaries than -O2, and may use more ram
#COMMON_FLAGS="-Ofast -pipe -march=native -flto -fgraphite-identity -fipa-pta -fmerge-all-constants" #I believe this is as aggressive as possible. -Ofast _will_ break some things when used globally!!


# For C programs built as modules from Go.

## Rust. -O3 is safe, as undefined behavior isn't really a thing for safe rust.
RUSTFLAGS="-C target-cpu=native -C opt-level=3 -C strip=symbols"
#RUSTFLAGS="${RUSTFLAGS} -C lto=fat -C embed-bitcode=yes -C prefer-dynamic=no" #Needed for more aggressive LTO. atm most builds fail with this
#CARGO_PROFILE_RELEASE_LTO="true" #don't know how to make portage use rust profiles yet :p

## Golang. Its arch targeting is unconventional, _Please_ see its more info section below as there is no "native".
# Each architecture (defined in $GOARCH) has its own unique way to specify a minimum target, read below.
# You _*WILL*_ have to change these values by hand!! $GOHOSTARCH and $GOHOSTOS won't have values yet.
GOOS="${GOHOSTOS}" #value example: "linux"
GOARCH="${GOHOSTARCH}" #value example: "amd64" < note how the value is lowercase
# Arch-specific minimum target tuning. Having things set for another arch is harmless. I've set the below to Go's default values.

## USE & USE EXPAND variables
#CPU_FLAGS_*="" read lower for more info
    lto pgo graphite threads ithreads openmp 
#    opengl gles2 vulkan vaapi vdpau kms #graphics related
    -seccomp -telemetry

To get what you should be using instead of -march=native, emerge app-misc/resolve-march-native and run it.

For what to put in your platform's CPU_FLAGS variable, emerge app-portage/cpuid2cpuflags and run it. It will tell you the name of the variable you want to set and what it should be set to. This controls some optional hand written assembly optimizations.



For (Free) Pascal optimizations create/edit this file:

FILE /etc/fpc.cfg
# -Cp<CPU> is which CPU to target. To get a list of supported options run `fpc -ic`.
# There is a chance -O4 may cause problems.

More info on flags


* GCC_optimization <- Read this in its entirety. I'm not going to paraphrase, the devs have done a good job at explaining :)
* Safe_CFLAGS has a list of -march and other flags for almost all consumer CPUs, if you still have it set to native look at this.


* rustc -C help
* rustc --print target-cpus
* <- Forum about LTO


All optimizations shown here are for gc, aka, dev-lang/go. Optimizations for gccgo are included in my other userpage here
* <- This will explain what you need to set to optimize for your specific arch
* <- Relevant forum thread
* Want to know which value to set for amd64? Good luck, this is all I can find.

USE/USE expand:
These are all conditional changes written into ebuilds. Notable flags I defined:

* -seccomp : disabling this disables a security feature that can negatively impact performance.
* lto : this enables LTO for packages with weird build systems, LTO will be enabled by language flags for all other packages.
* pgo : An optimization only some packages have and can only be enabled by USE.

Free Pascal:


Now, emerge -e @world to put all changes in effect!



* Ada's `gprbuild` build system seems to not have any standardized way to handle (optimization) flags via environment variables. This implies that there are several different environment vars formatted different ways. In the future I'll find the most common and see if I can implement them.


* Zig also has (optimization) flags, but the way Zig programs are built (build.zig) doesn't seem to have a standard way to listen to environment vars for individual flags. I've done an unnecessary amount of thinking of how to accomplish this, perhaps an official zig eclass, maybe some kind of patch to build.zig that makes it listen to user-chosen flags?


* shoot I forgot how haskell worked I'll be back