> 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>
Hi, Patrick Walton <pcwalton <at> cs.ucla.edu> writes:> Well, what I found myself wanting was a dynamic (strconcat) dag that > could join together strings and (call MyHook, INFILE, OUTFILE) dags.Can you give an example of how you would use (strconcat)? Wouldn't you also need (strcmp)?> :) For my plugin I would probably just add the Lua VM into the tree, > so that there wouldn't be a dependency at all.Okay, but please make sure that llvmc2 still compiles with lua scripting disabled. I.e. plain "make" should build a bare-bones version of llvmc2, and make BUILTIN_PLUGINS="lua ..." should build llvmc2 with lua scripting enabled.> Right. I'll work on a proof of concept when I get some time.Good luck!
Hello, Patrick>> 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.Honestly speaking, size does not matter much. We do care about speed, that's why we always prefer to generated sources to some scripting languages. Consider pretty typical situations, when compiler is invoked on bunch of small files at -O0 level, or during generation of PCH. In such situations the overhead of compiler driver is pretty visible and having extra VM will lead to funny situation, when pure compiler driver time will dominate over compilation time itself. If you don't care about such things - go ahead and think about sane design proposal, how one can hook any extra scripting language for llvmc2 without slowdown of 'main path'. This surely will be accepted! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
> If you don't care about such things - go ahead and think about sane > design proposal, how one can hook any extra scripting language for > llvmc2 without slowdown of 'main path'. This surely will be accepted!Okay, I'll focus on this. The idea is that the TableGen-based configuration would be preloaded into llvmc2, and then user-specified Lua scripts, if supplied, would be able to augment or modify the options, edges, and tools. This would give users an easy way to customize llvmc2 to fit their needs. Another interesting use case would be with out-of-tree front ends. They could supply a Lua script so that when the user installs a new language that uses the LLVM framework, their llvmc2 driver automatically gains support for it without having to recompile. Cross-compiling would be another example (and this is actually why I proposed this in the first place): the user could augment the stock llvmc2 with a script that replaces the system assembler and linker with the assembler and linker for the target. How does this sound? 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/20081118/7e1b1f5f/attachment.bin>