You probably could implement some workarounds in the compiler, though the linked Oodle blog-post does a good job of explaining why that isn’t feasible in this particular case:
The bug is not a flaw in the CPU logic as such, but rather the result of the CPU physically degrading due to design flaws. And for whatever reason, that degradation most frequently manifested as the mov instruction occasionally doing the wrong thing. Though the blog-post also makes it clear that this is not the only issue resulting from this degradation.
Moreover, the mov instruction is a very common instruction, so a general workaround for this problem would affect large parts of the resulting programs. For example, the 1-line function that Godbolt uses as its example code results in 3 mov instructions when compiled without optimizations:
intsquare(int num) {
return num * num;
}
becomes
"square(int)":
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov eax, DWORD PTR [rbp-4]
imul eax, eax
pop rbp
ret
I was kinda surprised as well that you couldn’t annotate the function or something. But then again, an attribute like “please don’t use this instruction” sounds like something that’s pretty hard to integrate in the code generation. What kind of flag would you use? I don’t think you want to apply that flag to everything, just to that particular function.
I would expect it to apply to everything. You don’t want to hit the issues in the first place.
It seems like a weighing of (safe) CPU support vs better generated instructions. If you don’t care about a CPU generation, maybe because it’s old enough, or your target environment is restricted/controlled, you don’t enable it. If it’s still out there and you want to or have to support it, you enable it.
I would imagine a “CPU-Workaround-<Manufacturer>-<Generation>” or something, and if you enable it, it completely evades the instruction constellations that cause the issues and uses alternatives instead.
Maybe it could have “evade completely” (same code runs on every CPU) and “generate cpu-checked workaround code branches” (faulty CPUs execute a different branch) as alternatives.
Shouldn’t compilers (in this case LLVM) cover such CPU bugs with flags? So users can commit to either evading CPU bugs or not.
It’d also be a good entry-point and overview of what CPU bugs are out there. Without it, how are you supposed to know about and evaluate them?
You probably could implement some workarounds in the compiler, though the linked Oodle blog-post does a good job of explaining why that isn’t feasible in this particular case:
The bug is not a flaw in the CPU logic as such, but rather the result of the CPU physically degrading due to design flaws. And for whatever reason, that degradation most frequently manifested as the
movinstruction occasionally doing the wrong thing. Though the blog-post also makes it clear that this is not the only issue resulting from this degradation.Moreover, the
movinstruction is a very common instruction, so a general workaround for this problem would affect large parts of the resulting programs. For example, the 1-line function that Godbolt uses as its example code results in 3 mov instructions when compiled without optimizations:int square(int num) { return num * num; }becomes
"square(int)": push rbp mov rbp, rsp mov DWORD PTR [rbp-4], edi mov eax, DWORD PTR [rbp-4] imul eax, eax pop rbp retI was kinda surprised as well that you couldn’t annotate the function or something. But then again, an attribute like “please don’t use this instruction” sounds like something that’s pretty hard to integrate in the code generation. What kind of flag would you use? I don’t think you want to apply that flag to everything, just to that particular function.
I would expect it to apply to everything. You don’t want to hit the issues in the first place.
It seems like a weighing of (safe) CPU support vs better generated instructions. If you don’t care about a CPU generation, maybe because it’s old enough, or your target environment is restricted/controlled, you don’t enable it. If it’s still out there and you want to or have to support it, you enable it.
I would imagine a “CPU-Workaround-<Manufacturer>-<Generation>” or something, and if you enable it, it completely evades the instruction constellations that cause the issues and uses alternatives instead.
Maybe it could have “evade completely” (same code runs on every CPU) and “generate cpu-checked workaround code branches” (faulty CPUs execute a different branch) as alternatives.