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

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

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

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 couldn't reproduce this. What system are you u...

...gt; need to interface with LLVM's CommandLine library somehow (easy to do > in C++, where we just auto-generate the appropriate objects). Right. I'll work on a proof of concept when I get some time. I anticipated this would be a bit of a hard sell, but I really think that a scriptable llvmc2 would be the right thing for several use cases. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachme...

...compiler driver is pretty visible and having extra VM will lead to funny situation, when pure compiler driver time will dominate over compilation time itself. 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! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

...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 self-hosted. No extra perl/python/lua/php/whatever_language_your_know interpreter. Thus is generated c++ sources from .td descriptions. Allowing you to write plugins in arbitrary language, which will dynamically populate compilation graphs, etc is just nice "side effect&...

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 plugin I've found some things to be difficu...

> 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, would be able to augment or modify the options, edges, and too...

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, > 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 will be able to generate llvmc plugins, it will p...

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 not yet ready to be merged...

...easier to > use. As Anton said, that was intentional. We wanted to minimize the number of dependencies and keep the driver lean and mean. > How would you feel about a plugin that reads its configuration from > an external specs file written in, say, Lua? It looks like the > design of llvmc2 allows plugins that dynamically set up nodes and > edges instead of statically reading them, and it could be a good > solution for drivers with complex requirements. I could start work > on such a thing if you thought it was a good idea. I think that such a project could be useful - as lo...

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

...fo.cpp:43: error: duplicate explicit instantiation of `bool llvm::X86TargetAsmInfo<BaseTAI>::LowerToBSwap(llvm::CallInst*) const [with BaseTAI = llvm::TargetAsmInfo]' I'm not seeing this issue on my Macbook with GCC 4.0.1. And it seems that there is a file missing at llvm/tools/llvmc2/ plugins. The Makefile in llvm/tools/llvmc2/plugins/Base says: LLVMC_PLUGIN = Base include ../Makefile.common In which ../Makefile.common is missing. I'd be very appreciated if somebody could fix these issues. Thank you very much! Best, Haohui

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

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

On Thursday 02 October 2008 12:42, David Greene wrote: > But let's say you _could_ write such a pattern (because I can). The input > DAG looks like this: > > 0x391a220: <multiple use> > 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 > 0x391ac10: <multiple use> > 0x391c8b0: v2f64 = scalar_to_vector