Thanks for the reply!> The plan now is to make this functionality easier to use, so you'll be able to > just say: > > llvmc2 --load MyPlugin.td MyFile.cpp > > and have llvmc2 build and load MyPlugin.td behind the scenes.That sounds like a good idea. Part of the reason I suggested making the system less dependent on TableGen is that in the process of developing a plugin I've found some things to be difficult to express in the current framework. For instance, when parsing options, I've found that often I want to save some kind of information in a variable and then use that variable when constructing the command line. This is not possible without hooks, but hooks are limited in what they can do (they can only do simple string substitution). Basically, my concern with TableGen is that a lot of work has gone into creating a small domain-specific scripting language in TableGen, when maybe a real scripting language would be easier to use (not to mention to maintain), and would have the added benefit of not having to recompile. How would you feel about a plugin that reads its configuration from an external specs file written in, say, Lua? It looks like the design of llvmc2 allows plugins that dynamically set up nodes and edges instead of statically reading them, and it could be a good solution for drivers with complex requirements. I could start work on such a thing if you thought it was a good idea. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081117/887daf9d/attachment.bin>
Hello, Patrick> Basically, my concern with TableGen is that a lot of work has gone into > creating a small domain-specific scripting language in TableGen, when > maybe a real scripting language would be easier to use (not to mention > to maintain), and would have the added benefit of not having to recompile.One of the main design concerns is that llvmc2 should be completely self-hosted. No extra perl/python/lua/php/whatever_language_your_know interpreter. Thus is generated c++ sources from .td descriptions. Allowing you to write plugins in arbitrary language, which will dynamically populate compilation graphs, etc is just nice "side effect" :) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
On Nov 17, 2008, at 11:16 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote:> Hello, Patrick > >> Basically, my concern with TableGen is that a lot of work has gone >> into >> creating a small domain-specific scripting language in TableGen, when >> maybe a real scripting language would be easier to use (not to >> mention >> to maintain), and would have the added benefit of not having to >> recompile. > One of the main design concerns is that llvmc2 should be completely > self-hosted. No extra perl/python/lua/php/whatever_language_your_know > interpreter. Thus is generated c++ sources from .td descriptions.Why is this though? It doesn't seem to me that creating a new domain- specific language buys us much if anything over using a well-tested, small embedded language. I keep hitting bugs in the llvmc2 TableGen implementation. Correct me if I'm wrong here, but it looks to me like TableGen was never really intended to be a programming language, which is what llvmc2 uses it as in some cases. Patrick
Hi,> I've found that often I want to save some kind of information in a > variable and then use that variable when constructing the command > line. This is not possible without hooks, but hooks are limited in > what they can do (they can only do simple string substitution).Would it help if it was allowed to pass arguments to hooks? So that you could write, for example: (cmd_line "$CALL(MyHook, $INFILE, $OUTFILE)")> Basically, my concern with TableGen is that a lot of work has gone > into creating a small domain-specific scripting language in > TableGen, when maybe a real scripting language would be easier to > use.As Anton said, that was intentional. We wanted to minimize the number of dependencies and keep the driver lean and mean.> How would you feel about a plugin that reads its configuration from > an external specs file written in, say, Lua? It looks like the > design of llvmc2 allows plugins that dynamically set up nodes and > edges instead of statically reading them, and it could be a good > solution for drivers with complex requirements. I could start work > on such a thing if you thought it was a good idea.I think that such a project could be useful - as long as it is implemented strictly as a plugin (of course, some things could be changed/added to the core to make life easier for you - but we're not going to add a dependency on the whole lua VM). However, to make this work you will need more than just the ability to modify the compilation graph. One thing that comes to mind is the need to provide Lua implementations for the various Edge* classes (otherwise you can't use edges with non-default weights). You'll also need to interface with LLVM's CommandLine library somehow (easy to do in C++, where we just auto-generate the appropriate objects).
> Would it help if it was allowed to pass arguments to hooks? So that > you could write, for example: > > (cmd_line "$CALL(MyHook, $INFILE, $OUTFILE)")Well, what I found myself wanting was a dynamic (strconcat) dag that could join together strings and (call MyHook, INFILE, OUTFILE) dags.> As Anton said, that was intentional. We wanted to minimize the number > of dependencies and keep the driver lean and mean.Definitely a good idea, which is why I wouldn't suggest Python or Perl :) For my plugin I would probably just add the Lua VM into the tree, so that there wouldn't be a dependency at all. It's under a compatible MIT/X11 license and is only 17k lines of ANSI C that should add around 150k to the driver. For me the driver is about 350k, so that would mean a driver around 500k, which doesn't seem that big of a difference.> I think that such a project could be useful - as long as it is > implemented strictly as a plugin (of course, some things could be > changed/added to the core to make life easier for you - but we're not > going to add a dependency on the whole lua VM). > > However, to make this work you will need more than just the ability to > modify the compilation graph. One thing that comes to mind is the need > to provide Lua implementations for the various Edge* classes > (otherwise you can't use edges with non-default weights). You'll also > need to interface with LLVM's CommandLine library somehow (easy to do > in C++, where we just auto-generate the appropriate objects).Right. I'll work on a proof of concept when I get some time. I anticipated this would be a bit of a hard sell, but I really think that a scriptable llvmc2 would be the right thing for several use cases. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081117/6373e335/attachment.bin>