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

Peter Collingbourne peter at pcc.me.uk
Tue Oct 4 09:51:33 PDT 2011


On Tue, Oct 04, 2011 at 08:16:39AM +0100, James Molloy wrote:
> Hi Peter,
> 
> This is a good idea, and I've been meaning to do it for a while.
> 
> I have multiple other projects based on LLVM, and while tblgen is extremely
> useful the barrier to entry to using it in spinoff projects is the cost of
> maintaining a backend under the main LLVM tree, and not being able to keep
> your code together.
> 
> The way I was going to go was slightly different to yours, in that I was
> going to make a couple of the main tblgen headers public and have clients
> #include those, create shared objects and pass them to the main LLVM tblgen
> as a dynamically loaded backend, much how opt has the "-load" option.
> 
> With your method, I still see the possibility of the content of the "main"
> tblgen file changing and breaking spinoff projects' code. The worst part
> about this though is that because their main function will be held out of
> tree in their own sourcebase, they won't get proper merge conflicts and
> fixing the changes may be manual and arduous.
> 
> Have you thought about these kind of developers (hobbyist and academic) and
> how your changes will affect them, for better or worse?

Hi James,

I have also considered the dynamic loading approach, which I discounted
for the main reason that making dynamic loading work on all platforms
(especially Windows) will introduce unneeded complexity and create
unsolved problems.  For example, I understand that dynamic loading
of compiler passes does not currently work on Windows, and the issue
would be similar for tblgen backends.  Since I don't really care about
Windows I am not willing to expend a large amount of effort to solve
this problem for Windows.  Perhaps once the Windows people resolve
this issue we can rethink this.

The "main" function for TableGen clients is at its core very simple;
only a few lines of code that initialise the stack trace dumper,
parse the command line and call the "TableGenMain" function.  If you
look at utils/TableGen/TableGen.cpp, you will see that most of the
complexity is in the TableGenAction subclass, which will be different
for every project anyway.  I'm quite confident that "main" shouldn't
need to change very often (or if it does, the changes would be very
easily resolvable).

Thanks,
-- 
Peter



More information about the llvm-commits mailing list