LLVM Developers Are Still Debating How To Handle The Intel JCC Erratum Mitigation

Disclosed back in mid-November was the Intel JCC Erratum that required a CPU microcode update to mitigate and that in turn had broad performance hits. But via toolchain updates, some of that overhead can be offset. The GNU Assembler patches were quickly merged and new options exposed for helping to decrease that performance hit but on the LLVM side the developers are still working on their mitigation with some design decisions still to be made.

Some LLVM work has been merged for changing the behavior of jump instructions crossing 32-byte boundaries. But developers from Intel and the upstream LLVM community have been working on finishing it up and related work around the "Jump Conditional Code" erratum.

A new discussion on the LLVM mailing list outlines the current LLVM state of the JCC mitigation and next steps.

We now have in tree support for alignment of such branches via nop padding, and limited support for padding existing instructions with either prefixes or larger immediate values. This has survived several days of dedicated testing and appears to be reasonably robust. The padding support applies both to branch alignment for the mitigation, but also normal align directives.

The original patches proposed a somewhat different approach than we've ended up taking - primarily because of memory overhead concerns. However, there was also a deeper disagreement on the original review threads (D70157 and others) which was never settled, and we seem to be at a point where this needs attention. In short, the question is how assembler support should be handled.

The issue being decided upon now is the handling of user-provided .s files being fed to the assembler rather than just the output from the compiler. Those interested in more of the technical details of the mitigation and the matters being discussed now can check out this mailing list thread.

The Intel CPU microcode mitigating the JCC Erratum is now quite widespread and most Linux users should find themselves using it already for this change that affects Skylake through Cascadelake processors. The GNU Assembler support is out there but aside from Clear Linux I haven't seen any Linux distributions making use of the new assembler flags by default for helping out the performance. Obviously on the LLVM side, the matter is still being resolved.