similar to: [LLVMdev] notes on llvmc2

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?

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

WikiFormatting for code documentation? :-) -scooter On Tue, Dec 9, 2008 at 7:56 AM, Mikhail Glushenkov <foldr at codedgers.com>wrote: > [Chris asked me to bring this up on the mailing list some time > ago, but I couldn't get to it. Sorry for that.] > > Since the beginning, I used ReST [1] for documenting llvmc, instead of > plain HTML that was used historically. In my

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

And the followup: http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote: > > This may be of interest: > > http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html > > People implementing a new Haskell compiler explain why LLVM is an > unsuitable target

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

> 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

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

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

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

It's nice that he claims it's way too high overhead without any, you know, data. Then again, he also thinks writing a good native code generator isn't that difficult, so .... On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at codedgers.com> wrote: > This may be of interest: > > http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html > > People

On Thu, Jul 16, 2009 at 7:48 PM, Mikhail Glushenkov<foldr at codedgers.com> wrote: > Hi Daniel, > > Daniel Dunbar <daniel <at> zuster.org> writes: > >> >> Ultimately I think a better API would be to provide a generic class >> which represents an executed operating system process, and includes >> operations to wait for its completion, redirect

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, 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. It's a compiler that compiles a near-subset of Standard ML to C++, with an architecture deliberately very similar to TableGen. The code is

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:

> 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

I don't think this is the right direction for the system library to go. The System library is supposed to expose generic OS independent interfaces, not be a generic way for clients to get OS information. Ultimately I think a better API would be to provide a generic class which represents an executed operating system process, and includes operations to wait for its completion, redirect its IO,