Thought bubble from my LTO PortGroup

[RJVB (René Bertin)]

Mostly thinking aloud :)

I know at least one of the core devs is aware of the LTO PortGroup I have in my MacStrop tree and which provides an easy way to get builds with link-time and compiler optimisation.

​https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/LTO-1.0.tcl

This blurb is mostly about the cpucompat variant, which came to be as a means to generate code targetting the common subset of extended instructions (SSE* and the like). It allows me to build generic code that will run as optimally as possible on all CPUs I have in the house. For me that comes into play mostly when I boot a backup clone of my Linux root disk in a VM on my Mac, and is defined as

default LTO.compatcpu westmere
default LTO.compatflags {-msse4.1 -msse4.2 -msse3 -mssse3 -msse2 -msse -mmmx -mpclmul}

if {[variant_isset cpucompat]} {
    default LTO.cpuflags "-march=${LTO.compatcpu} [join ${LTO.compatflags} " "]"
}

But MacPorts chiefly targets Apple's closed hardware universe, where I think we know exactly what minimum extended instruction set is available for each OS version. I'm not aware that Apple ever introduced new OS versions able to run on less capable processors so I don't think that one could end up in a situation where a port built for OS-i won't run on OS-i+1 .

In other words, "base" should be able to define its own OS-specific equivalents for cpucompat and compatflags and then -fvectorize to the default compiler options (unless -O3 is now the default optimisation level). (I often use configure.optflags="-Os -fvectorize" for big ports nowadays.

Auto-vectorisation has come a long way since its debuts, still doesn't always make a really noticeable difference (I like to think it will when a system gets real busy, as older systems often are) but I've never yet observed it causing problems.