Careful with the word "unlamination", since it is usually referring to a different thing than the usual splitting up of micro-fused ops at execution. As far as

Careful with the word "unlamination", since it is usually referring to a different thing than the usual splitting up of micro-fused ops at execution. As far as micro-fusion, there are at at least three interesting possibilities for the uops originating from the same instruction (with a memory operand): 1) No micro-fusion at all, e.g., for shrx and friends. The number of fused domain and unfused domain uops is the same. 2) Fusion in the uop cache (and probably the IDQ), but not the RAT and later stages. This is a case where the instructions are fused at decode, but are "unlaminated" before rename, and hence it usually has similar performance to no fusion at all (but it does save space in the uop cache), since RAT is more likely to be a performance limitation. If you look at the performance counters to determine fusion, this will look like case (1) (unless you check the DSB uops delivered one, I guess). 3) Full micro-fusion. This is the "normal" micro-fusion that people usually talk about: fusion persists through the RAT and get split up for execution. As far as I know, "unlamination" refers to the process that distinguishes between type (2) and type (3) - the former are unlaminated and the latter aren't. The existence of type (2) isn't even really clear from the classic sources like Agner's doc, and the behavior has changed even on recent archs (e.g., Skylake unlaminates less scnearios than Haswell). All the gory details are here: https://stackoverflow.com/q/26046634/149138 https://stackoverflow.com/q/26046634/149138 About RMW ops, it usually ends up as 4 unfused uops (store data, store AGU, load, ALU) which get fused into two micro-fused pairs (the store, and the load-ALU) op, not fully fused into one uop. The same concerns about type (2) vs type (3) likely apply also, although I haven't tested it.