【论文导读】Scalable Hardware Memory Disambiguation for High ILP Processors

随着issue宽度和pipeline深度的增加，in-flight的指令的数量也会增加，成为了功耗和latency的瓶颈。我们提出了两种基于Bloom filter的机制来进行filter： searching filtering, 使用hash算法来减少查询LSQ和entries的次数；以及 state filtering，用来减少保存在LSQ中数量。

对于out-of-order memory issue的系统来说，memory ordering会遇到三个问题：

1. 需要检查所有发射的load来决定是否program order的earlier的store存在相同物理地址，如果存在，需要使用store的数值；
2. 所有发射地store都需要检测是否program order的later的load存在相同的物理地址，如果存在，则需要进行更正的reflow措施；
3. hardware需要保证所有load和store满足memory consistency model。
   在众多的processors中，这部分的实现叫做load/store queue(LSQ)。其中的一个缺点就是，随着in-flight指令数目的增加，需要进行检测的memory ordering violation数量也相当的增加。

传统的Memory Ordering Hardware

Store Buffer
Store Buffer可以用来buffer存在复杂计算的overlap的store操作。更多的现代的架构将store buffer分为pre-completion和post commit buffer两部分。pre-completion buffer，现在被称为store queues，存储了speculatively issue而且还没有commit的store操作。post-commit buffer则是memory系统优化，来增加写带宽。

这些buffer都允许store forward操作，即如果later的并且物理地址完全相同的load操作被发射，则从store获取数值。

与此同时，这些store buffer也需要保证向同一个物理地址的两次store操作时需要满足program order的。

Load Buffer
Load Buffer 最初是用来保存临时的load的数值，即如果older的store操作正在completing，来允许后面非memory的操作使用load的value。更激进的out-of-order的load操作 buffer会speculative从data cache 中获取数值，甚至即使更older的store操作还在等待 issue。
Load Buffer就成为了用来检测dependency violation的工具，如果older的store操作发射出来，发现和speculative的load的地址完全匹配，就会进行pipeline flush。也有的处理器使用load来增强memory consistency model，防止相同地址的load操作 out-of-order发射，并且一个其他core的store操作在两个load操作的时间间隙内。
随着instruction window size的增加，memory操作地址完全一样的概率增加，并且 incorrect order的概率也增加，都会增加pipeline flush的概率。
目前memory dependency predictor也被引入来解决这个问题，使得和未发射的older store地址一致的load操作不太可能 被speculatively发射，它们会defer类似的load操作。

Optimization Opportunities
作者测试了在LILP（low Instruction Level Parallelism即真实的microarch，本文使用的是alpha 21264）架构以及HILP （High ILP，即其他环节比如分支预测等都perfect的micro arch）的情况下memory reference的比例。

可以看出在理想情况下，1/4的memory address是不match的，因此存在3/4的优化空间。

Improvement

Searching Filter
与传统的结构是通过存储完整的地址的进行搜索不同的是，本文采用了Bloom Filter Predictor(BFP)来对可能过滤对LSQ的搜索。即如果地址进行hash之后，发现地址匹配，则进行搜索；不匹配，则不需要进行搜索，这样大大的减少了需要搜索的次数。

如上图所示，load操作查询store表，store操作查询load表，如果要检测多处理器的load操作，那么还需要一个Bloom Filter来检测invaliation操作。

State Filter
如果未来的processor支持8K的instruction window，那么将会需要2000-3000大小的LSQ，然而实际上只有一小部部分的地址是需要保存用来进行matching比对的。
ideal的LSQ中的load只保存addressing match的load，但是store操作因为确实需要commit，所以需要全部都存储。

如上图所示，我们采用了Address Match Predictor(AMP)来检测一个load是否会和store全地址匹配。如果load预测不匹配，那么他将会被hash存入一个exclusive Bloom Filter（EBP），保存所有未被存入load queue的load操作的hash值。如果load被预测为将会匹配，那么它会被放入load queue中。
当store操作issue后，store会检测load queue和EBP（用来检测是否存在false predict）。如果store操作发现EBP中存在flase predict，那么就需要进行pipeline flush。

Summary
本文总体上是基于High ILP中LSQ过于巨大的问题，使用search filter来减少搜索的次数，使用state filter来减少保存load操作的数量。

欢迎关注我的公众号《处理器与AI芯片》