search for: pcwalton

> 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

...deliberately very similar to TableGen. The code is not yet ready to be merged by any means - it has many failure cases and may not compile at any given time - but I thought that before I go further I should send a proposal to the list. The WIP code, for the curious, is here: http://github.com/pcwalton/llvm-nw/tree/miniml If TableGen is a language that allows users to specify records of domain-specific information, TableML is designed to be a configuration language that is designed to be allow users to specify how to *construct* records of domain-specific information. TableML has a plugin ar...

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

Hi, I've been working on TableML some more and I thought I would see about how I should work on getting it into the tree, since it's nearing a usable state. So far I have a (mostly) working interpreter for a subset of Standard ML. After interpreting a set of definitions, the interpreter passes the resulting values off to a backend for serialization. The idea, for those who

Hi, I'd like to try tackling the x86-64 exception handling bug (#3214), since it's essentially the one thing preventing D from working on x86-64. I noticed that Anton among others have done some work on it, so I thought I would ask to see what information they or anyone else might have on the problem. Thanks, Patrick

> 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,

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

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