[all-commits] [llvm/llvm-project] d5c28c: [X86] Move CPUKind enum from clang to llvm/lib/Sup...

[topperc via All-commits]

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

  Changed paths:
    M clang/include/clang/Basic/X86Target.def
    M clang/lib/Basic/Targets/X86.cpp
    M clang/lib/Basic/Targets/X86.h
    M llvm/include/llvm/Support/X86TargetParser.def
    A llvm/include/llvm/Support/X86TargetParser.h
    M llvm/lib/Support/CMakeLists.txt
    A llvm/lib/Support/X86TargetParser.cpp

  Log Message:
  -----------
  [X86] Move CPUKind enum from clang to llvm/lib/Support. NFCI

Similar to what some other targets have done. This information
could be reused by other frontends so doesn't make sense to live
in clang.

-Rename CK_Generic to CK_None to better reflect its illegalness.
-Move function for translating from string to enum into llvm.
-Call checkCPUKind directly from the string to enum translation
and update CPU kind to CK_None accordinly. Caller will use CK_None
as sentinel for bad CPU.

I'm planning to move all the CPU to feature mapping out next. As
part of that I want to devise a better way to express CPUs inheriting
features from an earlier CPU. Allowing this to be expressed in a
less rigid way than just falling through a switch. Or using gotos
as we've had to do lately.

Differential Revision: https://reviews.llvm.org/D81439