>Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 20, 2014 3:48 pm wrote:
>> Stubabe (Stubabe.delete@this.nospam.com) on January 17, 2014 12:58 pm wrote:

> I assume the vector pipelines are in-order with a 4-cycle latency and round-robin scheduling, just like
> KNC. So the L0 cache does not affect scheduling. One L0 miss becomes an L1 access, so that's fine. Two
> L0 misses would create a bubble in one of the pipes, but that should be rare enough and cheap enough
You should assume no such thing - we don't know much about that yet. Also the Load unit IS scheduled out of order on Silvermont. So Load-op Instructions will issue to the load queues and then on completion to the FPU issue queue (in order or not) so the results have to be passed via the bypass network to the FPU (given the size of the operands it is very unlikely source operands are bundled with the instruction itself so will be read on issue - in fact Silvermont doesn't do this for power reasons). Note the FPU part of the instruction may have other dependencies so may have sit in the queue for a while. So either -> bypass network is large, complex with extensive FIFO etc -> i.e. power inefficient. Or more simply you allocate a temporary PRF entry and get the load unit to writeback to that (which obviously does not save a PRF access). Whatever you choose the mechanism has to handle the worst case for program correctness. Neither looks cheaper than a PRF access.

> That's exactly the load patterns we're observing in the examples Eric has posted. Remember,
> the L0 hit ratio does not have to be very high. It just allows to reuse memory operands without
> requiring a second L1 load port and to allow reducing the register file complexity.
>
Yes but the OoO is still throwing around lots of extra instructions to the load units filtered or not. That's more work right there. That's load queue slots and load issue bandwidth eaten up. All of that contributes to the cost benefit analysis you can't look at a hypothetical structure in solation and ignore the knock on effects elsewhere.

> First of all there are also continued savings from simplifying the register file. Secondly the
> L0 cache is utterly tiny so any cost is easily won back tenfold by hits. Look at the 'filter
> cache' and 'cached load/store queue' for similar very cheap additions with big savings.
An L0 with low hit rate will not allow you to make much difference to the register file especially if you want to support 3 operand instructions like FMA without stalls and other penalties. The absolute worst thing you can do for power on a OoO uarch is start introducing bubbles and micro-architectural hazards everywhere. Something that helps 10% of cases does nothing for the other 90% so better make sure the it doesn't introduce new issues of its own.


> > A far better explanation (if you really want to avoid two
> > load ports) is Load elimination (especially as Intel
> > actually have a patent filed for that) i.e. where identical
> > loads are eliminated by PRF redirection during rename.
> > But the only reason a complier would explicitly take advantage
> > of such a technique is to reduce total instruction
> > counts or to deal with register pressure, it would not offer power savings v normal register use.
>
> Why would it not save power? You're saving accessing the L1 cache for the same operand.
>
Obviously if loads are repeated as a natural function of code behaviour load elimination will be beneficial for both power and throughput. But a compiler actively using that mechanism over allocating a register when either method will just use a PRF read anyway will not save power. If anything it will use more as the load will have to matched to the preceding one and then effectively replaced by the operation the compiler could have explicitly used in the 1st place.

> the Haswell code looks as expected and it would be trivial to use it for the AVX-512. Compiler developers
> look at assembly output all day long, so this isn't something that just slipped their attention.

Its also silly unrepresentative microbenchmark code. Almost certainly not what the compiler is designed for: crap in -> crap out. I can produce lots of innocuous code sequences that randomly make otherwise good compilers suddenly vomit up crap only then to make a very sophisticated optimisation a few lines below. So yes I could easily believe it is a compiler issue as I have seen much worse (e.g. 32bit versions of the MSVC compiler often produce comically bad code but its not a problem restricted to MS).