LLVM folks: so given this https://www.tomshardware.com/software/mozilla-firefox/after-a-year-firefox-finally-stops-crashing-on-intels-raptor-lake-cpus-mozilla-releases-new-version-patch-critical-flaw-on-intel-13th-gen-and-14th-gen-cpus and the patch https://phabricator.services.mozilla.com/D301917, how we feeling about maybe adding a codegen option for Raptor Lake mitigation that is just "don't emit mov \[...,\], [abcd]h"
it's amazing that Intel is still selling these when we now have multiple projects independently working around certain byte stores in the 80386-era integer instruction subset failing, but here we are, I guess
@rygorous Wasn't the root cause too much voltage that degraded the CPU faster than expected or something like that?
Maybe with that fixed in firmware new/not previously used CPUs don't have the problem anymore
(still wouldn't buy one)
@Doomed_Daniel yes, but these are still (apparently) the first thing to fail (my guess being that this is probably one of the paths with the least timing slack at high clocks)
@rygorous @Doomed_Daniel oh wow that's crazy, just reading about this whole story now. could this be fixed, even for already-affected CPUs, with a microcode update?
@floe @Doomed_Daniel Not really how microcode works.
They've issued like 5 microcode fixes to try and make their voltage/frequency scaling logic less aggressive but apparently in newer uCode revisions this got worse again. (see comment 20 in https://bugzilla.mozilla.org/show_bug.cgi?id=1950764)