> 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>
Hello, Patrick> How does this sound?You need to be really careful and separate different aims. Currently you will definitely sacrifice speed for scriptability. As for cross-compilers - all $ENV & hooks stuff was introduced to transparently switch from one compiler tree into another. Maybe this approach needs to be generalized / rethought. In general, I'd not go this way due to reasons I already mentioned. Maybe it will be better to formulate the aims you want to achieve and think how they can be solved within current infrastructure, or, if this won't be enough - think how it can be extended in the full generality. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Nov 18, 2008, at 10:56 AM, "Anton Korobeynikov" <anton at korobeynikov.info > wrote:> Hello, Patrick > >> How does this sound? > You need to be really careful and separate different aims. Currently > you will definitely sacrifice speed for scriptability. As for > cross-compilers - all $ENV & hooks stuff was introduced to > transparently switch from one compiler tree into another. Maybe this > approach needs to be generalized / rethought. > > In general, I'd not go this way due to reasons I already mentioned. > Maybe it will be better to formulate the aims you want to achieve and > think how they can be solved within current infrastructure, or, if > this won't be enough - think how it can be extended in the full > generality.Ok, so runtime scripting languages are out, owing to speed concerns. I still don't think that TableGen is good as a programming language though. I think it's inevitable that a simple graph description is not enough for an industrial-grade compiler driver, with the plethora of options it needs to support. IMO a tiny domain-specific programming language would be better. Maybe such a language could be implemented with LLVM itself. That is, the llvmc configuration language could be compiled into .so files with the aid of LLVM. I keep running into bugs in TableGen because it uses token pasting to create C++ program logic. This works fine for data description, but LLVMC tries to make function bodies this way. I think this approach is more trouble than it's worth. Would a minimalist custom language that statically compiles configuration into LLVMC be the right design, or would you suggest something else? Patrick