https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128445
--- Comment #1 from Hongyu Wang <hongyuw at gcc dot gnu.org> --- The latency can be seen at uops.info for XCHG (R64, R64). For a swap, the "operand 1 -> 1" and "operand 2 -> 2" latencies should be 0, since each result only comes from the other input. uops.info reports them as 1 on every Intel core from Sandy Bridge to Arrow Lake (P- and E-cores), but as 0 on Nehalem/Westmere and on Zen+ to Zen5: https://uops.info/html-lat/ADL-P/XCHG_R64_R64-Measurements.html#lat1->1 https://uops.info/html-lat/NHM/XCHG_R64_R64-Measurements.html#lat1->1 So since Sandy Bridge, xchg reg,reg makes both results wait for both inputs. Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2026-November/737953.html
