similar to: [LLVMdev] Proposal for TableML, llvmc2 configuration language

Hi Patrick, > I've been working on a proof of concept for a new configuration language > for LLVM: specifically for my needs in llvmc2, but I have tried to make > it as generic as possible for use throughout LLVM if other projects > would like to make use of it. Your proposal seems interesting - I especially like that you are using a functional language. When your compiler

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

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

Being fully aware that llvmc2 is work-in-progress, here are some notes nethertheless: I already compiled llvm, but llvm-gcc was still compiling. Now I tried the new llvmc2: $ llvmc2 -opt -v main.c llvm-g++ -c -x c main.c -o /tmp/llvm_KeApik/main.bc -emit-llvm llvmc2: Can't find program 'llvm-g++' * after this, the directory /tmp/llvm_KeApik was not removed * why using /tmp at all?

Hello, Since the old llvmc was removed, is it now OK to rename llvmc2 to llvmc? I'll update man pages accordingly.

On Nov 25, 2008, at 9:11 AM, Mikhail Glushenkov wrote: > Hello, > > Since the old llvmc was removed, is it now OK to rename llvmc2 to > llvmc? > I'll update man pages accordingly. yes please! -Chris

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..."

Hi Holger, first of all, thanks for your feedback. > I already compiled llvm, but llvm-gcc was still compiling. Now I tried the new llvmc2: > > $ llvmc2 -opt -v main.c > llvm-g++ -c -x c main.c -o /tmp/llvm_KeApik/main.bc -emit-llvm > llvmc2: Can't find program 'llvm-g++' > > > * after this, the directory /tmp/llvm_KeApik was not removed Strange, I

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

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

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

This implements -dry-run for llvmc2: $ llvmc2 -dry-run main.c llvm-g++ -c -x c main.c -o /tmp/llvm_bGw2gN/main.bc -emit-llvm llc -f /tmp/llvm_bGw2gN/main.bc -o /tmp/llvm_bGw2gN/main.s llvm-gcc -c -x assembler /tmp/llvm_bGw2gN/main.s -o /tmp/llvm_bGw2gN/main.o llvm-gcc /tmp/llvm_bGw2gN/main.o -o a.out $ llvmc2 -dry-run -opt main.c llvm-g++ -c -x c main.c -o /tmp/llvm_UGZtwL/main.bc -emit-llvm opt

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

> 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

Hi, I'm currenly working with clang, so I don't have any llvm-gcc installed (I used to have the 4.2 release version, but that broke a lot of tests). A number of tests (test/CFrontend and test/C++Frontend for example) won't run if you don't have llvm-gcc installed, which is good. However, the test/LLVMC tests do run, but fail. These tests test the llvmc2 compiler driver, but they

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

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:

Hi Mark, Mark Muir <mark.i.r.muir <at> gmail.com> writes: > I want to be able to package this compiler as a cross-compiler > - a single binary to go from C to assembly for that target. It > should define a macro (as shown above) to allow the target to > be identified by source code. I was thinking of doing this > using llvmc to capture the above command-line. Is that

Hi all, The current repository (revision 56968.) does not compile on my Linux box (with GCC 3.4.6): X86TargetAsmInfo.cpp:41: error: duplicate explicit instantiation of `bool llvm::X86TargetAsmInfo<BaseTAI>::ExpandInlineAsm(llvm::CallInst*) const [with BaseTAI = llvm::TargetAsmInfo]' X86TargetAsmInfo.cpp:43: error: duplicate explicit instantiation of `bool

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