These were never working with native CPU features. In this branch,
we fix native CPU features not being enabled on Windows, and regress
f128 language features. In the llvm10 branch, all this is fixed,
and the tests are re-enabled.
Previously it was a tagged union which was one of:
* baseline
* a specific CPU
* a set of features
Now, it's possible to have a CPU but also modify the CPU's feature set
on top of that. This is closer to what LLVM does.
This is more correct because Zig's notion of CPUs (and LLVM's) is not
exact CPU models. For example "skylake" is not one very specific model;
there are several different pieces of hardware that match "skylake" that
have different feature sets enabled.
comment from this commit reproduced here:
I have observed the CPU name reported by LLVM being incorrect. On
the SourceHut build services, LLVM 9.0 reports the CPU as "athlon-xp",
which is a 32-bit CPU, even though the system is 64-bit and the reported
CPU features include, among other things, +64bit.
So the strategy taken here is that we observe both reported CPU, and the
reported CPU features. The features are trusted more; but if the features
match exactly the features of the reported CPU, then we trust the reported CPU.
This reverts commit 6dd514ac8aa3ee2e5c6fd0374469d361ccfce5b9.
This strategy won't work for arm 32-bit; instead need to try to figure
out how to get more bits into the bit set.
Previously, buffers were used with toOwnedSlice() to create c strings
for LLVM cpu/feature strings. However, toOwnedSlice() shrinks the
string memory to the buffer's length, which cuts off the null terminator.
Now toSliceConst() is used instead, and the buffer is not deinited
so that the string memory is not freed.
