Ricardo B (ricardo.b.delete@this.xxxxx.xx) on January 9, 2014 11:19 am wrote:
> G. Gouvine (no_reply.delete@this.noone.fr) on January 9, 2014 9:10 am wrote:
> >
> > Isn't it possible to imagine another structure than the L0 cache to obtain the same effect (i.e.
> > good code shouldn't use a register for reused memory operands) ? The result of the load could
> > be sent on the result bus when it is available, with address information to determine which load
> > it is. If multiple instructions accessed the same address, they both receive the result.
> >
> > It still needs some logic to collapse accesses using the same unmodified operands, but probably less
> > than a L0 cache since there is no copying. Reusing the same memory operand in a short time is thus
> > free, and the compiler choses not to add instructions to load it in a temporary register.
>
> Maybe you could design a load queue that, when it has multiple
> loads to the same address, can serve them efficiently.
> That could encourage some use of redundant loads.

Doesn't that require some sort of cache to keep the data around for the subsequent loads, and several bits of compare logic to match equal loads and invalidate things on overlapping stores? Sounds a whole lot like my L0 cache. Would you use symbolic addresses or virtual addresses for your enhanced load queue?

> > Last idea, since memory accessing operations would be tranformed into multiple micro-ops
> > AFAIK, they could collapse micro-ops using the same registers earlier, at the register
> > renaming stage - although this seems a bad idea from a complexity point of view.
>
> That would make the renaming stage quite complex, due to the number of possible inputs.
>
> Finally, none of these possibilities fully explain the assembly Eric provided us with, as it also
> contained redundant loads quite far apart, with many other instructions and loads in between.

It's disingenuous to expect a perfect hit rate. That said, an L0 cache the way I describe it would have a hit on every redundant load in Eric's examples with just three entries per thread. Still absolutely tiny. Four probably works too. More than that would defeat the point, methinks. Either way this would require precise simulations with various workloads to determine the best number of L0 entries.