title: Intel JCC Erratum - what is the effect of prefixes used for mitigation?
body: <p>Intel <a href="https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf" rel="nofollow noreferrer">recommends</a> using instruction prefixes to mitigate the performance consequences of JCC Erratum.</p>
  <p>MSVC if compiled with <a href="https://docs.microsoft.com/en-us/cpp/build/reference/qintel-jcc-erratum?view=msvc-170" rel="nofollow noreferrer"><code>/QIntel-jcc-erratum</code></a> follows the recommendation, and inserts prefixed instructions, like this:</p>
  <pre><code>3E 3E 3E 3E 3E 3E 3E 3E 3E 48 8B C8   mov rcx,rax ; with redundant 3E prefixes
  </code></pre>
  <p><a href="https://devblogs.microsoft.com/cppblog/jcc-erratum-mitigation-in-msvc/#what-does-the-software-mitigation-do" rel="nofollow noreferrer">They say</a> MSVC resorts to NOPs when prefixes are not possible.</p>
  <p>Clang has <code>-mbranches-within-32B-boundaries</code> option for this, and it prefers <code>nop</code>, multi-byte if needed (<a href="https://godbolt.org/z/399nc5Msq" rel="nofollow noreferrer">https://godbolt.org/z/399nc5Msq</a> notice <code>xchg ax, ax</code>)</p>
  <p>What are the consequences of 3E prefixes, specifically:</p>
  <ul>
  <li>Why does Intel recommend this, and not multi-byte NOPs?</li>
  <li>What are the consequences for unaffected CPUs?</li>
  <li>Reportedly, a program runs faster with <code>/QIntel-jcc-erratum</code> on AMD, what could be possible explanations?</li>
  </ul>