I'm not entirely sure if clz is based on a cpu feature. nauty's configure script checks for a cpu feature and for gcc support for popcnt but only for gcc support for clz.

If anyone know more here we may be able to get away with only disabling popcnt.

At least this page lists a popcnt feature but no clz. Could still be that gcc's builtin_clz is based on some other cpu feature, as https://stackoverflow.com/questions/9353973/implementation-of-builtin-clz seems to suggest.

Wikipedia says that all AMD CPUs from the latest decade (2007 for first supporting CPUs) seems to support both popcnt and clz/lzcnt; Intel has started supporting clz/lzcnt only in 2013.

Thanks for looking into that. I'm still a bit confused as to weather or not gcc has software fallbacks at runtime when those instructions are missing, but at least for popcnt it apparently hasn't.

We should probably specify somewhere what the minimum required CPU instruction set for Nixpkgs is. Not being able to use instructions like popcnt is pretty bad for performance.

@edolstra (this probably needs to be split off in a tracking issue) there's also the issue of the build farm having machines not having that instruction, while the others too. If the minimum supported features are defined, the build farm will need to be adjusted accordingly.

The solution might be to default to performant builds, and the package requiring a requiredSystemFeature of something like cpu-popcnt, every machines tagged accordingly. An end-user requiring this to be run on platforms missing the feature could override the package as needed.

And a question: would it be helpful if all cpu features were made available as a system feature within nix, maybe automatically "cpu:${feature}", meaning that it's not a configurable variable, but a runtime variable; no need to add new features to blacklist for reproducibility / perfs purposes, only require the right one. (Though it'd need policing in Nixpkgs to not abusively tag all features as required when not needed).

I'm thinking we already have similar issues in aarch64-land, where I've had binaries failing to run on Cortex-A53, being built on a Cortex-A96; though rebuilding locally it worked. (Don't remember what exactly.) As far as reproducibility goes, I don't know how ready we are with facing CPU features detection. I can't find anything quickly about that on the reproducible builds' website.

So uh, recap of the issues:

• Some software detects CPU features.
• Our build farm is heterogenous CPU-wise.

And things that aren't issues:

• Things are being run on mis-matched CPUs with differing feature sets.