authorgravatar for gootvilig.davidhai@gmail.comd18g <gootvilig.davidhai@gmail.com> 2021-06-17 23:37:38+03:00
committergravatar for andrew@ziglang.orgAndrew Kelley <andrew@ziglang.org> 2021-06-17 20:28:37-07:00
log71ec89383b07f4c9ea5bfc047074adec6ae6b533
tree49d765bef1fac956616d5bab1a05f6bc68b97924
parent4adbdcb587c4fadde0d1c45772d1b4d140bf6a46

Fix `lakemont` CpuModel (#9099)

Lakemont has no x86, no MMX, no SSE and no way of handling any fp-math. In theory LLVM is able to implicitly use the soft-float emulation library calls to legalize any such operation but, given Zig's use of many non-standard features, sometimes we hit a weak spot in the X86 codegen backend. Consider this as a work-around for this LLVM problem, fixing the problem in LLVM is not so high in my todo list as the target is pretty niche and Intel axed it in '19. (Commit message by @LemonBoy)

2 files changed, 5 insertions(+), 0 deletions(-)

lib/std/target/x86.zig+1
...@@ -2241,6 +2241,7 @@ pub const cpu = struct {...@@ -2241,6 +2241,7 @@ pub const cpu = struct {
2241 .cx8,2241 .cx8,
2242 .slow_unaligned_mem_16,2242 .slow_unaligned_mem_16,
2243 .vzeroupper,2243 .vzeroupper,
2244 .soft_float,
2244 }),2245 }),
2245 };2246 };
2246 pub const nehalem = CpuModel{2247 pub const nehalem = CpuModel{
tools/update_cpu_features.zig+4
...@@ -754,6 +754,10 @@ const llvm_targets = [_]LlvmTarget{...@@ -754,6 +754,10 @@ const llvm_targets = [_]LlvmTarget{
754 .llvm_name = "i686",754 .llvm_name = "i686",
755 .zig_name = "_i686",755 .zig_name = "_i686",
756 },756 },
757 .{
758 .llvm_name = "lakemont",
759 .extra_deps = &.{"soft_float"},
760 },
757 },761 },
758 },762 },
759 .{763 .{