similar to: [LLVMdev] Simple user question

Hi everyone, I'm going to be working with LLVM locally to implement and support some of our research projects. As a first step I am trying to set up our build process to support builds by both GCC and LLVM. I need to be minimally invasive to the current makefile structure, in particular, I don't want to add any conditional tests to what is already there (ie, I don't want the main

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?

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

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

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

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

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

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

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

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

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

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

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

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

Hello (my machine is a Debian/Sid/x86-64/Core2) Assuming I have one C source file chello.c, to compile it into a dynamically loadable thru dlopen shared object, I can run gcc -fPIC -shared -O chello.c -o chello.so I thought that, assuming I have one llvm source ehello.ll, the equivalent would be llvmc2 -opt ehello.ll -o ehello.so but it is not that simple. Any clues ? May I also