I've been working on some minor enhancements for llvmc2, but before I submit them, I'd like to know more about where the driver is going. Right now, llvmc2 uses TableGen at build time to statically create C++ files with hardcoded paths and command lines. The llvmc2 documentation seems to imply that the static TableGen-based configuration will eventually be replaced by some kind of dynamically loadable configuration system: "At the time of writing LLVMC does not support on-the-fly reloading of configuration..." It seems to me that a dynamic configuration not based on TableGen would be more in line with the "one-binary-fits-all" spirit of LLVM: that is, it seems strange that LLVM and clang don't have to be recompiled in order to run under different architectures, but llvmc2 does have to be recompiled in order to cross-assemble or cross-link, since the paths to the assembler and linker are hard-coded. Is there work being done on this? Thanks, 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/20081116/c87587c1/attachment.bin>
Hi, Patrick First of all, thanks for your interest in llvmc2! Your feedback is very valuable.> The llvmc2 documentation > seems to imply that the static TableGen-based configuration will > eventually be replaced by some kind of dynamically loadable > configuration system: "At the time of writing LLVMC does not support > on-the-fly reloading of configuration..."Actually, that line was removed from the documentation not very long ago:-) We now support dynamic plugins (via .so files and the -load option). So TableGen is going to stay, but you won't have to recompile the whole driver to alter llvmc2's behaviour (only your plugin). 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. If you still find this scheme cumbersome, I'll be glad to hear your comments.
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>