similar to: [LLVMdev] PATCH: -dry-run option for 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?

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

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

> 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

I'm using llvm-ld from SVN r41106 When issueing the command $ /usr/src/llvm/installed/bin/llvm-ld -v -stats -native -O1 -strip-all -o main \ .obj/conf.o .obj/configwriter.o \ -L/usr/share/qt3/lib -L/usr/X11R6/lib \ -lcrypto -lusb -lutil -lqt-mt -lXext -lX11 -lm -lpthread I get this output: Linking bitcode file '.obj/conf.o' Linked in file '.obj/conf.o' Linking

I realize I am one of the few who uses the segment registers (especially CS and DS) on the ia32 chips for example, and a definite few with complete segregation models that rival specialized physical processors... GCC still fails to use these correctly and if your LLVM still depends on either Generic or some of the RTL models they use in various processor definitions, I express concern for

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

Hello All, Sorry to rehash a question I am sure has shown several time but I cannot google up the answer from the lists. Does anyone know where I can get some royalty free, cost free music for my music on hold? I saw someone's post several weeks ago that said that this exists at a download site but I have not been able to find it. Thanks! Wiley Siler -------------- next

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:

I think I have experienced this when more than one module contains definitions for the same values. ie. it should only be a declaration in one of them. On 8/15/07, Holger Schurig <hs4233 at mail.mn-solutions.de> wrote: > I'm using llvm-ld from SVN r41106 > > When issueing the command > > $ /usr/src/llvm/installed/bin/llvm-ld -v -stats -native -O1 -strip-all -o main \ >

fucking hell, listserv... ---------- Forwarded message ---------- From: "Wilfred L. Guerin" <wilfredguerin at gmail.com> Date: Wed, 25 Jul 2007 10:54:46 -0500 Subject: Re: [LLVMdev] Segment Register Use To: Holger Schurig <hs4233 at mail.mn-solutions.de> I was very much expecting this style of response ;) I believe the following characteristics and class of example should

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

> If you use bison instead of yacc this bug is not exposed. > > Is this correct behavior? I guess so. bison is quite different to yacc, see "info bison". llvm depends on bison and this is quite well documented. At http://llvm.org/releases/2.3/docs/GettingStarted.html#software it says "bison" and specifically which version of Bison you've to use.

> The idea is to use llvm to put performance sensitive code into > a DLL that a Windows app can then use. > > This would build the performance sensitive code on the target > machine making it possible to exploit CPU specific x86 > vector instructions. Isn't this what Apple does with OpenGL, except that they skip the DLL step?