Explicit setting CPU_FLAGS_X86 for Skylake Xeon E3 v5

[eyesee]

Recently I fell into the trap having march=skylake in my CFLAGS which is not really supported by GCC 7. Now I have fixed this by setting CFLAGS march option to broadwell which makes sense and works so far. Thanks to all the people involved doing the hard work on that beast!

To squeeze out the last bit of my CPU I wonder if it makes sense to adjust the CPU_FLAGS_X86 setting to the output I am getting from the cpuid2cpuflags tool. The output I am getting does differ from the recommendation on the subarches wiki page for skylake and the given x86-64bit make.defaults for Intel Skylake. Could the output be different because I have a Xeon E3 instead of an iCore 3/5/7?

My ego profile shows the following:

arch: x86-64bit
build: current
subarch: intel64-skylake

The basic CPU_FLAGS_X86 option for Intel Skylake is according to the Subarches page:
aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

make.defaults for x86-64-bit Intel skylake contains the following (difference underlined):
aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

cpuid2cpuflags for my Xeon E3 v5 states there is another option available (difference underlined):
aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

It seems like f16c and pclmul are not used in many packages explicitly. But I am also compiling non-ebuild stuff and some stuff from my own overlay. In general I have not that much insight how CPU flags are used and I do not know if the compilation of GCC with those additional flags would automagically improve compilation results in general.

So my question is: would it be of any benefit to modify the CPU_FLAGS_X86 flag to reflect what cpuid2cpuflags spits out?

Thanks!

eyesee

[drobbins]

Hey, so I think no one is really telling you the obvious -- you found a small bug, and I'm going to fix it with a commit to the profiles so that pclmul is added to CPU_FLAGS_X86 for skylake and skylake-avx512. ?

[lazlo.vii]

CPU_FLAGS used to be standard USE flags until some people that know a lot more about Portage than I do decided that they were tired of having a lot of USE flags for CPU options that could be enabled globally or per package and might have different meanings depending on which package you were talking about.  In an effort to stream line the code base and end the confusion they decided that all CPU options would be moved into the CPU_FLAGS settings.  I don't think that Portage will care if a CPU_FLAG is included even if no ebuilds use it.  I think that they will just be ignored in the same way that Portage ignores invalid USE flags.  So if I am right you could add "CPU_FLAGS_X86="12_dozen_hamsters_running_on_wheels" and Portage wouldn't not care, but PETA might.

[eyesee]

Well, thanks for your response! I know about the confusion of regular USE flags which could be handled differently depending on package. But CPU_FLAGS are probably more determined how these affect the resulting binary. Still the question for me is if modifying these flags has any benefit with the goal to squeeze ou the last bit of the processor capabilities... And yes, I know not every package will make use of the provided flags. For at least GCC I can imagine it possibly could have an effect.

[lazlo.vii]

It will only have an effect if:

 

1.)  The code being compiled comes from portage

and

2.)  The ebuild for that code specifies the use of the CPU_FLAGS.

 

So, no ebuild = no settings from Portage are used by gcc.

[eyesee]

Ok, then I assume at least no negative effect when enabling the provided additional cpu flags from cpuid2cpuflags, as I assume those reflect the actual cpu capabilities, no matter whether those are respected by an ebuild or not. I will see latest when my computers are on fire... Thank you!

[Oleg Vinichenko]

As said earlier setting too explicit flags can only benefit if package can utilize the exact instruction. For example the only one package in entire tree explicitly use pclmul instruction,

dev-libs/gf2x it has IUSE_CPU_FLAGS=" pclmul sse2 sse3 sse4_1 ssse3", which then has use_enable cpu_flags_x86_pclmul pclmul for the configure phase. Whether any other ebuilds in tree can use this instruction is unknown. Same is applicable to other less frequently used instructions. In most cases the flags will be ignored.

[eyesee]

Thanks for clarification, Oleg!