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 a

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.