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

[Chris Lattner]

On Oct 3, 2011, at 4:48 PM, Peter Collingbourne wrote:

> 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.

Ok, that would be great.

> 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.

I find this unfortunate, but if shared libraries aren't working on windows (and if this isn't reasonably fixable?) then I guess it is the right way to go.  Shared libs really aren't fixable on windows? :)

>> 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.

Ok, I didn't understand how this was going to work, I agree it makes sense in principle.

> 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

That makes sense to me.

>> 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.

Ok.  This is an unconventional way to structure things, but if we can't pluginize tblgen, then I guess it's the best way to go.

>> 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.

Ok thanks.

-Chris