[all-commits] [llvm/llvm-project] 636d31: [X86] Don't imply -mprfchw when -m3dnow is specifi...

[topperc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 636d31a5c341ff2ca5eefd6075ff059eb60b5a80
      https://github.com/llvm/llvm-project/commit/636d31a5c341ff2ca5eefd6075ff059eb60b5a80
  Author: Craig Topper <craig.topper at intel.com>
  Date:   2020-06-25 (Thu, 25 Jun 2020)

  Changed paths:
    M clang/lib/Basic/Targets/X86.cpp
    M clang/test/Preprocessor/predefined-arch-macros.c
    M llvm/lib/Target/X86/X86.td
    M llvm/lib/Target/X86/X86InstrInfo.td
    M llvm/lib/Target/X86/X86Subtarget.h
    M llvm/test/CodeGen/X86/prefetch.ll

  Log Message:
  -----------
  [X86] Don't imply -mprfchw when -m3dnow is specified. Enable prefetchw in the backend with 3dnow feature.

The PREFETCHW instruction was originally part of the 3DNow. But
it was given its own CPUID bit on later CPUs just before 3DNow
was deprecated.

We were setting the -mprfchw flag if -m3dnow was passed or the CPU
supported 3dnow unless -mno-prfchw was passed. But -march=native
on a CPU without the PRFCHW CPUID bit set will pass -mno-prfchw.
So -march=k8 will behave differently than -march=native on a K8
for example.

So remove this implicit setting from the frontend and instead
enable the backend to use PREFETCHW if 3dnow OR prfchw is enabled.

Also enable PRFCHW flag on amdfam10/barcelona which seems to be
where this CPUID bit was introduced. That CPU also supported
3dnow.