[llvm-dev] Discuss about the LLVM SW mitigation to Jump Conditional Code Erratum

[Zhang, Annita via llvm-dev]

Changed the data into plain text.

Hi all,

We have more data based on LLVM test suite and SPEC2017. It covered the performance, code size and build time. It collected the performance of the SW mitigation on the servers w/o MCU and with MCU, the prefix padding and nop padding, the padding to jcc+fused+jmp and the padding to all types of branches. I expect the data can help us to move forward and make decision.
For the code size of Chrome, Firefox, or Safari, we don't have data on hand. We are willing to work with community to get those data.

Below is the LLVM test suite we measured including the performance, code size and build time.
The data indicates some performance effect (1.7%) from the microcode update, which was reduced to 0.5% with the SW mitigation of prefix padding. The code size increase in test suite is ~0.5%. And the compile time increase is ~2%.
Comparing with hw_sw_prefix and hw_sw_nop, the exec_time difference is within -0.5%~0.5%, which may be a within the margin of error.
Comparing with hw_sw_prefix and hw_sw_prefix_align_all, the exec_time difference is even less at 0.1%.
Given that LLVM test-suite is a relatively small benchmark, we do not conclude which padding is preferable, hw_sw_prefix, hw_sw_nop or hw_sw_prefix_align_all.

Table 1 - test suite result data
LLVM test-suite     Baseline       sw_prefix         sw_nop     sw_prefix_align_       hw         hw_sw_prefix     hw_sw_nop    hw_sw_prefix_ali
  compile_time       0.276           0.282           0.277           0.282           0.276           0.282           0.277           0.282
   exec_time        286.465         285.017         287.125         285.696         291.294         287.766         285.027          288.2
   code_size         3.868           3.889           3.888           3.895           3.868           3.889           3.888           3.895


Table 2 - normalized test suite result data
LLVM test-suite     Baseline       sw_prefix         sw_nop     sw_prefix_align_       hw         hw_sw_prefix     hw_sw_nop    hw_sw_prefix_ali
  compile_time       1.000           1.021           1.005           1.022           1.000           1.021           1.005           1.022
   exec_time         1.000           0.995           1.002           0.997           1.017           1.005           0.995           1.006
   code_size         1.000           1.005           1.005           1.007           1.000           1.005           1.005           1.007


Test date:

              2019/11/25



System Configuration:

Platform: Intel Internal Reference Validation Platform

OS: Red Hat* 8.0 x86_64

Memory: 192 GB

CPUCount: 2

CoreCount: 40

Intel HyperThreading: yes

CPU Model: Intel(r) Xeon(r) Gold 6148 CPU @ 2.40GHz

Microcode w/o microcode update: 0x200005e

Microcode with microcode update: 0x2000063



Compiler options:

              ***sw_prefix: -x86-branches-within-32B-boundaries

              ***sw_nop: -x86-align-branch-boundary=32 -x86-align-branch-prefix-size=0 -x86-align-branch=fused+jcc+jmp

              ***sw_prefix_align_all: -x86-align-branch-boundary=32 -x86-align-branch-prefix-size=5 -x86-align-branch=fused+jcc+jmp+indirect+call+ret

Notes:



1.       Baseline means the system w/o microcode update and w/o SW mitigation.

2.       sw_prefix means SW mitigation of prefix padding is applied to a system w/o microcode update.

3.       sw_nop means SW mitigation of nop padding is applied to a system w/o microcode update.

4.       sw_prefix_align_all means SW mitigation of prefix padding is applied to all impacted branches including call, ret and indirect jump, to a system w/o microcode update.

5.       hw means the microcode update is applied w/o SW mitigation.

6.       hw_sw_prefix means both microcode update and SW mitigation of prefix padding are applied.

7.       hw_sw_nop means both microcode update and SW mitigation of nop padding are applied.

8.       hw_sw_prefix_align_all means microcode update is applied, and SW mitigation of prefix padding is applied to all impacted branches including call, ret and indirect jump.

9.       The data in 2nd table is normalized as the ratio vs. baseline (i.e. baseline =1, so the smaller the better).

10.   The test was built with an engineering LLVM compiler plus the SW mitigation patch. The performance data may be variant from build to build.

11.   The tested Microcode 0x2000063 is an engineering version with microcode update. The production version 0x2000064 and above contain the microcode update.



For more complete information about performance and benchmark results, visit www.intel.com/benchmarks<http://www.intel.com/benchmarks>.  For specific information and notices/disclaimers regarding the Jump Conditional Code Erratum, visit https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191216/33c53a93/attachment-0001.html>