[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-14 Thread Erich Keane via Phabricator via cfe-commits
erichkeane abandoned this revision. erichkeane added a comment. First, updated this incorrectly. Second, going to do this work over a few patches to take advantage of work that Craig did in the backend. https://reviews.llvm.org/D39521 ___

[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-14 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 122934. erichkeane added a comment. Re-ran clang-format, which now has more sane decisions in CGBuiltin.cpp https://reviews.llvm.org/D39521 Files: lib/Basic/Targets/X86.cpp lib/CodeGen/CGBuiltin.cpp Index: lib/CodeGen/CGBuiltin.cpp

[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment. In https://reviews.llvm.org/D39521#913337, @rsmith wrote: > Thanks, this looks like a nice cleanup. I wonder of some of the switches over > `CPUKind` (setting default features and macros) could also be moved into the > .def file, but let's get this landed first and

[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment. Thanks, this looks like a nice cleanup. I wonder of some of the switches over `CPUKind` (setting default features and macros) could also be moved into the .def file, but let's get this landed first and then see if that looks like an improvement.

[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane created this revision. In anticipation of multiversioned target support (and just for code sanity), this patch extracts as much of the X86 TargetInfo CPU values into its own file, unifying the support. This has the side-effect of being a touch more liberal in what it accepts than GCC,