https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #20 from Maxim Egorushkin <maxim.yegorushkin at gmail dot com> --- (In reply to Drea Pinski from comment #19) > (In reply to Maxim Egorushkin from comment #18) > > Another example, but now with the general purpose registers only, > > demonstrates a similar problem: > > No that is a totally different issue dealing with TImode passing. That is > recorded as PR 114134 and PR 120588; that is a regression in GCC 14+. I see now, says a blind man. --- May be I am biased towards finding flaws in gcc-generated machine code because that's what I run in production, and only look into clang-generated machine code when the former doesn't look good. Yet, I haven't come across an example where clang generated any unnecessary register moves. Whereas gcc emits register moves left and right as if they were 0-size 0-cost instructions. I wonder how clang manages to allocate registers flawlessly in all the cases I've looked into where gcc emits unnecessary register move instructions? --- Most perplexingly, despite its better register allocation, clang-generated machine code still executes slower in most of my micro- and macro-benchmarks, compared to that of gcc. Playing with `llvm-mca-20`, I couldn't help noticing that it outputs wrong latency numbers for some Zen3 instructions I happen to remember latencies of, e.g.: vmovmskpd r32, ymm 1 (correct is 7) vcvtsi2sd 4 (correct is 9) vcomisd 4 (correct is 7) vmaskmovpd ymm 8 (correct is 10) vpmovsxbd ymm 11 (correct is 9) pop 5 (correct is 4) vpermps ymm 7 (correct is 8) vsqrtsd 21 (correct is 20) mov r32, imm32 1 (correct is 0) <all stores> 1 (stores take much longer than 1 cycle, but the register may become available for other uses in 1 cycle) Wrong instruction latency costs could be the reason why clang-generated code runs slower than that of gcc, despite the often sub-optimial register allocations of the latter.
