Re-factor TableGen docs

This is mainly a movement of content around to give place to new content
allowing different people to add bits to it in the right place. There is some
new content, but mostly to fill the gaps left by text movement.

I'm dropping the old syntax documentation as it has the problem of being
quickly outdated by changes and largely unnecessary to people not involved
in creating the language, but using it, which is the whole point of the
documentation.

llvm-svn: 204351

1 files changed, 31 insertions, 0 deletions

diff --git a/llvm/docs/TableGen/Deficiencies.rst b/llvm/docs/TableGen/Deficiencies.rst
new file mode 100644
index 00000000000..a00aecd342d
--- /dev/null
+++ b/llvm/docs/TableGen/Deficiencies.rst
@@ -0,0 +1,31 @@
+=====================
+TableGen Deficiencies
+=====================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+Despite being very generic, TableGen has some deficiencies that have been
+pointed out numerous times. The common theme is that, while TableGen allows
+you to build Domain-Specific-Languages, the final languages that you create
+lack the power of other DSLs, which in turn increase considerably the size
+and complexity of TableGen files.
+
+At the same time, TableGen allows you to create virtually any meaning of
+the basic concepts via custom-made back-ends, which can pervert the original
+design and make it very hard for newcomers to understand it.
+
+There are some in favour of extending the semantics even more, but making sure
+back-ends adhere to strict rules. Others suggesting we should move to more
+powerful DSLs designed with specific purposes, or even re-using existing
+DSLs.
+
+Known Problems
+==============
+
+TODO: Add here frequently asked questions about why TableGen doesn't do
+what you want, how it might, and how we could extend/restrict it to
+be more use friendly.