The "Retbleed" speculative execution vulnerabilities

The other issue with advanced scheduling is that an out-of-order execution design also benefits from a well-scheduled program. An out-of-order processor has a limited instruction window within which it can reschedule dynamically, and a well-scheduled program is set up so that all the rescheduling that can be done in that window is a consequence of the data the program is processing.

GPUs are a different case because they're designed for the world where single threaded performance is not particularly interesting - as long as all threads complete their work in a millisecond or so, we don't care how long each individual thread took. It's thus possible to avoid OoOE in favour of having more threads available to hardware, and better hardware for switching between threads when one thread gets blocked. In contrast, the whole point of CPUs in a modern system (with GPUs as well as CPUs) is to deal with the code where the time for one thread to complete its work sets the time for the whole operation.

I suspect that, for the subset of compute where the performance of a single thread is the most important factor, an out-of-order CPU is the best possible option. The wide-open question is whether we can design an ISA that allows us to avoid unwanted speculation completely; Itanium had that, because it was designed around making all the possible parallelism explicit, but Itanium wasn't a good ISA for out-of-order execution, and had low instruction density.

The other issue that Itanium's explicit speculation didn't account for is that we're starting to see uses of value prediction, not just memory access prediction; do we want to be explicit about all the possible speculative paths (e.g. "you can speculate that the value in r2 is less than the value in r3", or "you can speculate if you believe that r2 is between -16 and +96"), or do we instead want to find a good way to block speculation completely where it's potentially dangerous?