Skylakeのデコード帯域の謎

【後藤弘茂のWeekly海外ニュース】Skylakeアーキテクチャの謎その2 〜5命令デコーダと6命令uOPキャッシュ - PC Watch

上の記事では、Skylakeのデコーダは5wayに、uOP$の帯域は6uOPs/cycleになったとされています。IDFのスライドでも "Wider instruction supply with deeper buffers"と書かれている箇所があります。ただ、以前も書いたように私はuOP$やLSBの範囲ですら4uOPs/cycleを超えるパターンを見つけられていません。

nop(0x90) は特別扱いでuOPを生成しませんが、LSB/uOP$/L1の範囲で4OPs/cycleでした。
xorはレジスタリネーミングでuOPが消滅しますが、これも4OPs/cycleでした。
xorは実行ユニットで実行される場合ポート0156でイシューできますが、これが制限となっている可能性があるので、xorを4命令+ロード1命令やxorを3命令+ロード2命令を試してみましたが、これも4OPs/cycleでした。ロードはGPでもFPでも同じでした。
ライトバックの帯域制限がある可能性を考慮してxorを4命令+ストア1命令にしてみましたが、これも4OPs/cycleでした。

これらの値はHaswellと同じものです。

後藤氏の話はかなり具体的なもので真実味がありますが、実際の測定とは食い違います。仮に4uOP/cycleを超えられるとしても、制限は厳しそうですね。

また、分岐が少なくIPCを出しやすい数値計算系コードでは１命令のサイズが大きいため、16B/cycleのフェッチ帯域では5wayのデコーダを活用するのは困難です。

追記10/8

6uOPsというと、uOP$のエントリあたりのuOP数ですよね。だとすれば6uOPs/cycleというのは説明がついた気がします。ただしSkylakeで6uOPs/cycleになったわけではありません。Haswellでは1エントリに格納できるのは32Byteブロック内の連続命令列でしたがこれが64Byteに拡張されたという仮説です。もちろんこの場合もLSB以降は4uOPs/cycleにとどまり6uOPs/cycleでスケジューリングや実行ができるわけではありません。6uOPsの帯域が生かされるのはエントリに少ない命令数しか入っていない場合と分岐の場合です(トレースキャッシュではないので)。64Byteになれば前者のケースが緩和されます。