similar to: [LLVMdev] notes on llvmc2

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

Hello, Holger > Being fully aware that llvmc2 is work-in-progress, here are some notes nethertheless: First of all - Mikhael (the main author) sometimes cannot catch the mailing list directly, so please, CC him also (foldr at codedgers.com) I'll try to answer some questions and Mikhael will try to resolve others. > * why using /tmp at all? Same does gcc, we don't have pipe option

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

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

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

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

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

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

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

It seems that bugpoint (and llvmc2, etc.) is hard-wired to use gcc to do assembling and linking. I want to bugpoint-reduce a testcase that came from Fortran and so I need to invoke our compiler to do at least the linking step to get our Fortran libraries. Is there a way to do this via bugpoint's command-line interface or do I have to hack bugpoint's source? I can see how I might make

On Sun, Sep 21, 2008 at 9:27 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > This is an updated version of the patch that fixes some issues on VC++ > builds. Hi, FYI I just tried this (from r56534). I get an "error" (below) from cmake (2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj anyway. Project.sln opens and builds OK (modulo a build error in llvmc2

Hello, Luke > Is there any way to convince llvm-gcc to use llvm-ld during linking rather > than the system ld? If there isn't then I'll have to muck with the build a bit > more to add something like FINAL_CXX, but everyone will see that and it may > generate a bit of annoyance (and will need to be another thing that is > modified for our public releases). You can try to

Hi Dave, > It seems that bugpoint (and llvmc2, etc.) is hard-wired to use gcc to do > assembling and linking. I want to bugpoint-reduce a testcase that came > from Fortran and so I need to invoke our compiler to do at least the linking > step to get our Fortran libraries. you can always cheat and have gcc be a symlink to your compiler. Ciao, Duncan.