I guess Support is an OK place to park this particular pile of strings, enums,
and tables. The target feature CPU and feature parsing is very similar in
nature to triple parsing.
If this reaches the logical conclusion, we'll have a file per in-tree LLVM
backend, or 13 files. At that point, we might wish to make a new library.
================
Comment at: include/llvm/Support/ARMTargetParser.h:23
@@ +22,3 @@
+ // FPU names.
+ // FIXME: TableGen this.
+ enum FPUKind {
----------------
Actually, I'd much rather use .def files if possible. TableGen slows down
builds and is hard to understand. Sure, pre-processor macros are hard to reason
about, but they're *still* easier to understand than tablegen.
Also, so long as this library is in Support, and I think it will be here for a
while, this FIXME is unactionable because Support cannot depend on TableGen.
I think we can solve any inflexibility of .def files with a separate plain C++
source synonym table, like you currently have.
================
Comment at: lib/Support/ARMTargetParser.cpp:104-105
@@ +103,4 @@
+const char *
+ARMTargetParser::
+getFPUName(unsigned ID) {
+ if (ID >= ARM::LAST_FPU)
----------------
This style of separating the class name and the method name appears in LLVM,
but it's really uncommon and I don't want to encourage it. Do you mind not
using it?
http://reviews.llvm.org/D9435
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
