By: Stubabe (nospam.delete@this.nospam.com), November 15, 2012 11:38 am
Room: Moderated Discussions
anon (anon.delete@this.anon.com) on November 15, 2012 5:48 am wrote:
> Stubabe (nospam.delete@this.nospam.com) on November 15, 2012 5:14 am wrote:
> >
> > > But on paper that loop should only take 2 clk/loop on sandy due to co-issue of the fused branch,
> > > it takes 3 on Sandy (and 2 on Ivy) due to the loop buffer penalty of 1 clk/iteration
> >
> > Sorry I was thinking of MOVDQA it should be 3 on Sandy. But the loop buffer can issue max 4 uops/clk to the
> > renamer + 1 penalty clock so minimum loop time is 2 clocks irrespective of what the backend does with it.
> >
> >
>
> MOVAPS can only be issued to port 5 (maximum throughput is 1 / clk). Fused branch
> (dec+jnz) is also issued to port 5. What is the penalty you are talking about?
>
I saw somewhere (here?) that on Nahelam there was a 1 cycle penalty for each branch hit in the uop loop buffer. I guess that is gone now in Sandy.
> Another example:
>
> loop:
> xorps xmm0, xmm0
> xorps xmm0, xmm0
> xorps xmm0, xmm0
> dec ecx
> jnz loop
>
> This loop takes only 1 clk on both Sandy and Ivy. XORPS is also port5-only instruction, but
> due to the "zeroing idioms" feature, which definitely uses the renaming technique, they are
> executed without using the backend. If the MOV elimination in Ivy were done by the renaming
> technique, the MOVAPS example should take only 1 clk per loop like this XORPS example.
Or could it be a bookkeeping uop being issued due to the branch? After all a branch misprediction will need to recover state somehow. I'm sorry, but the uop fusion thing looks messy for the hardware to track to me, especially if multiple dependencies are present.
Perhaps the way to tell (sorry don't have an Ivy to test on) would be a longer chain (e.g. six MOVAPS) if it stays at 2 clocks we know its some kind of branch induced sync op being issued if it goes up above 2 then they really are using some uop fusion thing
> Stubabe (nospam.delete@this.nospam.com) on November 15, 2012 5:14 am wrote:
> >
> > > But on paper that loop should only take 2 clk/loop on sandy due to co-issue of the fused branch,
> > > it takes 3 on Sandy (and 2 on Ivy) due to the loop buffer penalty of 1 clk/iteration
> >
> > Sorry I was thinking of MOVDQA it should be 3 on Sandy. But the loop buffer can issue max 4 uops/clk to the
> > renamer + 1 penalty clock so minimum loop time is 2 clocks irrespective of what the backend does with it.
> >
> >
>
> MOVAPS can only be issued to port 5 (maximum throughput is 1 / clk). Fused branch
> (dec+jnz) is also issued to port 5. What is the penalty you are talking about?
>
I saw somewhere (here?) that on Nahelam there was a 1 cycle penalty for each branch hit in the uop loop buffer. I guess that is gone now in Sandy.
> Another example:
>
> loop:
> xorps xmm0, xmm0
> xorps xmm0, xmm0
> xorps xmm0, xmm0
> dec ecx
> jnz loop
>
> This loop takes only 1 clk on both Sandy and Ivy. XORPS is also port5-only instruction, but
> due to the "zeroing idioms" feature, which definitely uses the renaming technique, they are
> executed without using the backend. If the MOV elimination in Ivy were done by the renaming
> technique, the MOVAPS example should take only 1 clk per loop like this XORPS example.
Or could it be a bookkeeping uop being issued due to the branch? After all a branch misprediction will need to recover state somehow. I'm sorry, but the uop fusion thing looks messy for the hardware to track to me, especially if multiple dependencies are present.
Perhaps the way to tell (sorry don't have an Ivy to test on) would be a longer chain (e.g. six MOVAPS) if it stays at 2 clocks we know its some kind of branch induced sync op being issued if it goes up above 2 then they really are using some uop fusion thing
