Comment 5 for bug 1928097

Marco, We have a thing called *backend-subfeatures* which seems like it may be a fit for this.
The sparc/arith file is full of it. (Intentional double entendre)

A limitation of using subfeatures is that self-compile of SBCL should generally assume lack of any subfeature so that it emits code for any machine; and any alien variables (such as avx2_supported) are unavailable in self-compile.

Would you say that your intended user would compile SBCL on a machine that does/doesn't have avx2, and that the result of that compilation dictates whether subsequently compiled code can assume avx2; OR is it that you intend to compile SBCL on a least-common-denominator machine which can produce code for either?

My guess is that subfeatures will be fine even if it means that a few builtin functions are slightly suboptimal for some machines. Short of JIT-compilation to rebuild bits of SBCL at startup, we can't really produce a self-contained SBCL (that doesn't need to be rebuilt by running any post-build steps) that is at the same time maximally portable and maximally efficient on machines that have more CPU features available. But I can imagine a conflicting opinion.