[llvm-commits] [llvm] r140951 - in /llvm/trunk: ./ include/llvm/TableGen/ lib/ lib/TableGen/ utils/TableGen/

[Peter Collingbourne]

Hi Chris,

> What direction are you going here?

My intention is to move the Clang tblgen backends into the Clang
source tree by building the tblgen parser out into a library that
can be used to create tblgen-like tools, and creating LLVM and Clang
utilities which contain their respective backends and which are clients
of that library.  I'm trying to achieve this incrementally, by first
creating a TableGen library containing the parser and most of 'main'.
Currently tblgen is the only client, but I hope to replace this with
llvm-tblgen and clang-tblgen utilities.

> Are you committed to fixing these problems as follow-ons?

To address these issues:

> 1. All of the 'main' code and the top-level cl::opt's should be in utils/tablegen, not in TableGen/Main.h

Since llvm-tblgen and clang-tblgen would share most of the
implementation of their 'main' functions, I think it makes sense to
also put most of that code in the library.  The TableGenAction class
allows for tools to provide the relevant part of 'main' that calls
out to their backends.

I have noticed that this change is causing problems for shared library
users [1], and I apologise for not anticipating this.  I think that as
a single-purpose library, TableGen does not belong in the shared library,
so the most logical way to resolve this problem is to exclude it from
the shared library.

> 2. The tablegen headers (like the rest of it :) are a mess, they are not split properly between public and private headers.

I think that to begin with, the TableGen public interface should
provide the bare minimum to allow clients to write their own
tblgen-like tools.  To this end, the public interface consists of
the backend base class, the TableGenAction base class, the Record
data structure definitions and the 'TableGenMain' function.  I believe
that I've largely achieved this split with the current set of header
files in include/llvm/TableGen.

> 3. The tblgen code uses RTTI and EH, which none of the rest of the LLVM libraries do.
>
> So long as RTTI and EH don't invade tools other than the utils/TableGen executable, I'm ok with continuing to forget about #3, but #1 and #2 are pretty important.

I'm not addressing this problem.  The TableGen library and its clients
will be built with RTTI and EH.

Thanks,
-- 
Peter

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043687.html