andreas-a

Yes, it will use the same marker bytes.

Section 7.3 of the paper describes several such examples.

On Sandy Bridge, for example, the result of the "AESDEC XMM1, XMM2" instruction is ready 8 cycles after XMM1 becomes available. If only XMM2 is on the critical path, however, the result is already available after a bit more than one cycle.

On Nehalem, the SHLD R1, R2, imm instruction has, according to Intel's manual, http://instlatx64.atw.hu/, and IACA, a latency of 4 cycles. Agner Fog reports a latency of 3 cycles. The measurements on uops.info show that the latency from R1 to R1 is 3 cycles, while the latency from R2 to R1 is 4 cycles.

No, this is a different IACA-like tool. Our tool is not public yet.

The "number of clock cycles that are required for the execution core to complete the execution of all of the μops that form an instruction" is the definition that Intel uses in its manuals to define latency.

It is actually not the definition that uops.info uses. Instead, it uses a definition that takes into account that different operands of an instruction might be ready at different times (see section 4.1 of the paper that mentions Intel's definition as a "common definition" and then continues to introduce the new definition). Furthermore, uops.info also considers latency differences that can occur if an instruction uses the same register for multiple operands (the SHLD instruction is an example for this).

The testing code is not open source yet, but we plan to make it available in the near future. We are also working on a code analysis tool, similar to Intel's IACA, that uses the instruction data from http://www.uops.info/. Finally, we also plan to add data for AMD processors.