> Do you really mean the store forwarding buffer read, or do you mean the result forwarding network?

I was meaning a read from the store buffer, if the result is still available on the forwarding network the energy is most probably even lower

all of this are wild guesses, I'll be interested to have actual pJ figures for the different cases of loads, and even more interested to know if there is indeed a small read buffer / L0D cache to deal efficiently with sequences such as

vmovups zmm4, ZMMWORD PTR [rax+r14*4]
vcmpps k2, zmm13, ZMMWORD PTR [rax+r14*4], 17
vcmpps k6, zmm10, ZMMWORD PTR [rax+r14*4], 30
vfmsub132ps zmm6, zmm15, ZMMWORD PTR [rax+r14*4]
vfmsub132ps zmm4, zmm3, ZMMWORD PTR [rax+r14*4]
vfmsub132ps zmm5, zmm2, ZMMWORD PTR [rax+r14*4]

in the example above, a TLB access looks unecessary to me for 5/6 loads since the content of rax and r14 isn't changed between the loads in program order, the only thing to keep track of will be to which L1D cache lines (*) the buffered read data map to and to commit only if it wasn't invalidated, but I may well miss one thing or two as a software developer

* a single line for the common, well optimized 64B alignment case, btw this opzimization may be available only for this case with one buffer entry mapping to a single cache line