4 ms·

I think it has to be speculative? The optimization has to happen early, in the front-end (around allocation) at which point you'll not know if the load actuall

I think it has to be speculative? The optimization has to happen early, in the front-end (around allocation) at which point you'll not know if the load actually aliases the earlier store [1]. To get the zero latency, you take a guess and correct yourself if you are wrong. The non-speculative approach is basically the existing pre-memory-renaming approach: you probe the store buffer looking for earlier stores to the same address. This has also gotten much faster (3 cycles total on current Intel), but that's still a lot slower than 0 cycles (or 1 cycle total on Zen 2). > Also, is it value speculation or does it checks the state of the cacheline? I assume memory ordering is handled in the usual way, with an ordering nuke if a concurrency related misordering is detected. About how it's verified, I think it could either verify that the load actually came from the corresponding store (e.g., do the load and check that the SB entry used was the same as the predicted one), or it could verify that the value was the same: i.e., do the load and check that the value was the one used earlier based on the prediction. The latter would succeed in some additional cases. It should be easy to test the two cases (essentially, Agner's add test with different register, but add 0 not 1). --- [1] As a special case, you could prove that some loads alias some earlier stores when the addressing expression is the same (or can be proven equivalent), and there is no intermediate store, but evidently the AMD approach goes a ways beyond this since it allows for intermediate stores.

gpderetta 6y ago
>The optimization has to happen early, in the front-end (around allocation) at which point you'll not know if the load actually aliases the earlier store Yes, this is what I meant by alias predictor. It is probably a variation of the exiating aliasing predictor that allows reads to be speculatively reordered before previous stores of unknow address, except that on this case you would rollback on address mismatch instead of match.
- BeeOnRope 6y ago
  Well the existing alias predictor is in quite a different part of the pipeline: around the scheduler and execution engine and it gets feedback from the actual aliasing behavior. That said, I also thought they might feed this info back to the front-end in order to implement this. However, Agner's testing seems to show otherwise: it seems that "does it alias" is determined basically by a symbolic comparison of the addressing expressions. That is, [rax] matches [rax]. OTOH, [rax] doesn't match [rcx] even if those registers hold the same value. Also [rax + rcx * 2] matches [rax + rcx * 4] even though the scale factor is different! Perhaps it was too much work to compare the scale factors. The example 20.3 where he incremented the value in between the load and the store using a different addressing expression (but the same address) and it consistently took a misprediction seems to indicate that they are not using an aliasing predictor in the usual sense since this always-fails case should be easy to predict. Overall, quite interesting and some surprises there.

gpderetta 6y ago

>The optimization has to happen early, in the front-end (around allocation) at which point you'll not know if the load actually aliases the earlier store Yes, this is what I meant by alias predictor. It is probably a variation of the exiating aliasing predictor that allows reads to be speculatively reordered before previous stores of unknow address, except that on this case you would rollback on address mismatch instead of match.

BeeOnRope 6y ago
Well the existing alias predictor is in quite a different part of the pipeline: around the scheduler and execution engine and it gets feedback from the actual aliasing behavior. That said, I also thought they might feed this info back to the front-end in order to implement this. However, Agner's testing seems to show otherwise: it seems that "does it alias" is determined basically by a symbolic comparison of the addressing expressions. That is, [rax] matches [rax]. OTOH, [rax] doesn't match [rcx] even if those registers hold the same value. Also [rax + rcx * 2] matches [rax + rcx * 4] even though the scale factor is different! Perhaps it was too much work to compare the scale factors. The example 20.3 where he incremented the value in between the load and the store using a different addressing expression (but the same address) and it consistently took a misprediction seems to indicate that they are not using an aliasing predictor in the usual sense since this always-fails case should be easy to predict. Overall, quite interesting and some surprises there.