[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908

--- Comment #3 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=cadd2ca21765ebcb95b77ec94977b4e74e1edc1b

commit cadd2ca21765ebcb95b77ec94977b4e74e1edc1b
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2024-05-25 17:52:15 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2024-05-25 19:12:29 +0000

    Merge commit d0be944aa511 from llvm-project (by Simon Pilgrim):

      [X86] Add slow div64 tuning flag to Nehalem target (#91129)

      This appears to have been missed because later cpus don't inherit from
Nehalem tuning much.

      Noticed while cleaning up for #90985

    Merge commit 8b400de79eff from llvm-project (by Simon Pilgrim):

      [X86] Enable TuningSlowDivide64 on Barcelona/Bobcat/Bulldozer/Ryzen
Families (#91277)

      Despite most AMD cpus having a lower latency for i64 divisions that
converge early, we are still better off testing for values representable as i32
and performing a i32 division if possible.

      All AMD cpus appear to have been missed when we added the "idivq-to-divl"
attribute - this patch now matches Intel cpu behaviour (and the x86-64/v2/3/4
levels).

      Unfortunately the difference in code scheduling means I've had to stop
using the update_llc_test_checks script and just use old-fashioned CHECK-DAG
checks for divl/divq pairs.

      Fixes #90985

    This fixes possibly worse runtime performance on AMD Zen hardware, when
    using -march=znver4 (or any other znver), as opposed to -march=x86-64-v4
    or the baseline -march=x86-64. A similar fix is applied for Nehalem.

    PR:             278908
    MFC after:      3 days

 contrib/llvm-project/llvm/lib/Target/X86/X86.td | 6 ++++++
 1 file changed, 6 insertions(+)

-- 
You are receiving this mail because:
You are the assignee for the bug.