如果一个负载与两个早期的存储重叠（而且负载不完全包含在最早的存储中），现代英特尔或AMD x86实现可以从两个存储中转发以满足负载吗？
例如，考虑以下序列：
mov [rdx + 0], eax
mov [rdx + 2], eax
mov ax, [rdx + 1]
最后的2字节加载操作从紧随其后的存储器（store）中读取第二个字节，但从再前面的存储器（store）中读取第一个字节。这个加载操作能够被存储器（store）前向传递（store-forwarded），还是需要等待前面的两个存储器（store）都提交到L1缓存之后才能执行？
请注意，在此处“store-forwarding”包括任何可以满足从存储器中读取的数据的机制，即使它比最佳情况下“从单个存储器进行前向传递”的速度要慢。
至少在Haswell、Broadwell或Skylake处理器上不行。在其他英特尔处理器上，限制要么类似（Sandy Bridge、Ivy Bridge），要么更加严格（Nehalem、Westmere、Pentium Pro/II/III/4）。在AMD上也存在类似的限制。
来自Agner Fog的优秀优化手册:
英特尔和AMD CPU的微架构
§ 10.12 内存数据转发延迟
在特定情况下，处理器可以将内存写操作转发到同一地址的后续读操作中。 内存数据转发可以发生在以下情况下：
- 当写入64位或更少的数据，并且随后是相同大小和相同地址的读取时，不考虑对齐方式。
- 当写入128或256位，并且随后是完全对齐的相同大小和相同地址的读取时。
- 当写入64位或更少的数据，并且随后是包含在写地址范围内的较小的完全对齐的读取时。
- 当写入任何大小的对齐数据，并且随后是两个半部分、四个四分之一等大小的两个或多个读取，其自然对齐方式在写地址范围内。
- 当写入128位或256位的对齐数据，并且随后是不跨越8字节边界的64位或更小的读取时。
如果内存块跨越64字节的缓存行边界，则会出现2个时钟周期的延迟。如果所有数据都具有其自然对齐方式，则可以避免此问题。
内存数据转发失败的情况如下：
- 当写入任意大小的数据，随后是一个较大的读取
- 当写入任意大小的数据，随后是部分重叠的读取
- 当写入128位数据时，随后是跨越两个64位半部分之间边界的较小读取
- 当写入256位数据时，随后是跨越两个128位半部分之间边界的128位读取
- 当写入256位数据时，随后是64位或更少的读取，跨越四个64位四分之一之间的任何边界
一个失败的内存数据转发比成功的内存数据转发多需要10个时钟周期。如果128或256位的写入数据没有至少对齐16，则惩罚更高，大约为50个时钟周期。
强调部分已添加
英特尔和AMD CPU的微架构
§ 11.12 内存数据转发延迟
Skylake处理器在特定情况下可以将内存写操作转发到同一地址的后续读取操作中。与以前的处理器相比，内存数据转发速度快了1个时钟周期。
mov [rsp-16], eax mov [rsp-12], ebx mov ecx, [rsp-15]显示
ld_blocks.store_forwardPMU计数器确实会递增。这个事件的文档如下:ld_blocks.store_forward [此事件计算读取操作因为真正的存储锁定码(Block-on-Store)阻止存储转发而被阻止的次数。其中包括以下情况: - 先前的存储与加载冲突(部分重叠)
由于微架构限制，存储转发是不可能的
之前的锁定RMW操作没有被转发
存储具有不转发位设置(不可缓存/页面分割/掩码存储)
使用了所有阻塞存储(主要是栅栏和端口I/O)
这表明当一个只读部分地与最近的先前存储部分重叠时(即使考虑到更早的存储时完全包含在内)，存储转发确实会失败。
mov [rsp-16], eax; mov [rsp-12], ebx; mov ecx, [rsp-15]，然后ld_blocks.store_forward计数器增加了。因此，至少在英特尔公司看来，搜索存储缓冲区被认为是存储转发失败，但可以肯定的是，存储缓冲区中的最后两个条目足以计算负载值。 - Iwillnotexist Idonotexist相关：x86上失败的存储到加载转发的成本是多少？对于多个SF停顿未被同时处理的细节有更多说明，但在SF停顿正在进行时可以发生成功的SF。
有序Atom可能能够在不停顿的情况下进行此存储转发。
Agner Fog没有特别提到Atom的这种情况，但与所有其他CPU不同，它可以在从存储到更宽或不同对齐的加载时具有1个时钟周期的存储转发延迟。唯一的例外是在缓存行边界处，Atom表现非常糟糕（即使不涉及存储转发，对于CL-split加载或存储，也会有16个周期的惩罚）。
Intel/Agner将存储转发成功定义为，所有数据仅来自一个最近的存储，并具有低且（几乎）固定的延迟。
额外的（但有限的）延迟用于扫描整个存储缓冲区并按程序顺序组装正确的字节，并（如果必要或总是？）从L1D加载以提供未被最近存储的任何字节的数据。
我们不确定是否存在这种选项。
它还必须等待所有存储数据uop的数据，因为它必须遵守程序顺序。可能会发布一些关于具有未知存储地址的推测执行的信息（例如，猜测它们不重叠），但我忘记了。
等待所有重叠的存储提交到L1D，然后从L1D加载。
一些真正的x86 CPU在某些情况下可能会退回到此选项，但它们可能始终使用选项2而不引入StoreLoad屏障。（请记住，x86存储必须按程序顺序提交，加载也必须按程序顺序进行。这将有效地将存储缓冲区耗尽到此点，像mfence一样，尽管稍后对其他地址的加载仍然可以推测地存储转发或只从L1D中获取数据。）
Can x86 reorder a narrow store with a wider load that fully contains it?提出的锁定方案可以在需要将失败的store-forwarding清除到L1D的情况下工作。但由于在实际硬件上没有mfence就无法工作，这强烈表明实际的x86 CPU正在将存储缓冲区的数据与L1D中的数据合并。因此，在这种情况下存在并使用第二种选择。
请参见Linus Torvalds' explanation that x86 really does allow this kind of reordering，他回应了另一个人提出的与该SO问题相同的锁定想法。
我尚未测试store-forwarding失败/停顿惩罚是否可变，但如果不可变，那么它很可能会退回到在最佳情况下的转发不起作用时检查整个存储缓冲区。
希望有人能回答What are the costs of failed store-to-load forwarding on x86?，它正是询问这个问题的。如果我有时间，我会回答。
Agner Fog只提到一种存储转发惩罚的数字，并没有说如果缓存未命中存储在无法转发之前进行，这个数字会更大。 （这会导致很大的延迟，因为由于x86的强有序内存模型，存储必须按顺序提交到L1D。）他也没有提到数据来自1个存储器+ L1D和来自两个或多个存储器的部分情况是不同的，所以我猜在这种情况下它也有效。__m128i v = _mm_set_epi64x(a, b);将存储/重新加载到堆栈中，这在大多数CPU上对于大多数情况来说已经是错误的策略，因此出现了该错误报告）。虽然这不是好事，但据我所知，结果通常不会灾难性。
add cx, 127（66 opcode modrm imm8）是可以的，add cx, 128（66 opcode modrm imm16）不行。 还要注意，最近的英特尔CPU不会在mov-immediate上LCP停顿，只会在其他ALU指令上停顿。（而且，LCP停顿只会影响解码，而不会影响uop缓存）。 - Peter Cordes