similar to: [LLVMdev] A number of newbie questions

On Mon, 9 Jan 2006, Marcel Weiher wrote: > I am currently experimenting with LLVM to provide native code > compilation services for a project of mine I call Objective-Smalltalk, > and so far quite pleased with the results. I was able to JIT-compile > some functions that send Objective-C messages, and now look forward to > compiling full methods. Cool! > I do have a couple

Hi Chris, thanks for your answers! [large executables] > It depends on what you're building. A release build of LLVM (make > ENABLE_OPTIMIZED=1, with the results in llvm/Release) is > significantly smaller than a debug build. Even with that, however, > the binaries are larger than they should be (5M?). Noone has spent > the time to track down why this is to my

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

Hello LLVM-ers, The next sprint of PyPy will be held in Dallas, Texas, at the PyCon conference. Most of you know about the LLVM back-end of PyPy. So far, we use mostly the static compilation features of LLVM, but as we are progressing on the JIT side we are considering starting sometime soon working on just-in-time machine code generation backends. Clearly, LLVM might prove to be a good target

Hi Jeffrey, Thanks for pointing me in the right direction ! I'm not using the JIT in lazy mode, but it was fun to understand the lazy-stub code. Attached you will find a patch which follow your 1st option : a map Stub_address -> JITResolver instance, except that the used map is a "std::map" to apply the same upper_bound trick as in the map CallSiteToFunctionMap of the

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static

Thanks for the patch! I'll clean this up, convert your sample to a unit test, and commit it for 2.7. On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > Hi Jeffrey, > > Thanks for pointing me in the right direction ! > I'm not using the JIT in lazy mode, but it was fun to understand the > lazy-stub code. > > Attached you will

Thanks Jeffrey ! If possible, keep me inform (on revision number), I'm interested to see how you will do the unit test. (For my future patch... :) ). Thanks again. Olivier. On Wed, Feb 10, 2010 at 6:22 PM, Jeffrey Yasskin <jyasskin at google.com>wrote: > Thanks for the patch! I'll clean this up, convert your sample to a > unit test, and commit it for 2.7. > > On Sun,

On Sun, 21 Jan 2007, Marcel Weiher wrote: > just installed the new llvm 1.9 build and noticed that my code no > longer worked. It seems something has changed with > addPassesToEmitFile(). First, the arguments to that method changed so > that it no longer takes a PassManager, but only a > FunctionPassManager. Instead there is a addPassesToEmitWholeFile() > method, but that is

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

On Oct 8, 2009, at 9:19 AM, Kenneth Uildriks wrote: > Right now, on X86, creating multiple ExecutionEngines in the same > process causes an assertion. > Yes. This is by design. > If it's supposed to always be a singleton, should there be a way to > get the process's ExecutionEngine instance? > I can't see why. You could make a server to process llvm code. >

Hi Armin, > The next sprint of PyPy will be held in Dallas, Texas, at the PyCon > conference. Most of you know about the LLVM back-end of PyPy. So > far, > we use mostly the static compilation features of LLVM, How are you using the static compilation features? Are you able to do this via API calls or generating code that will be processed by tools? Thanks, Marcel

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?

well, as it so seems I need to bother everyone on the list with my pointless newb crap, but here goes. maybe there was a FAQ for all this, but I missed it. well, I am not trying to demean LLVM in any way here, only trying to understand and evaluate things from my POV is all... sorry if at all I seem arrogant or condescending... well, running a linecounter, it is about 223 kloc (c++ ...), +

On Oct 23, 2007, at 05:52, BGB wrote: > I am assuming then that some external assembler is used (such as > 'gas')?... In the static compilers, yes. The JIT directly serializes instructions into memory without the aid of an external assembler. There are also experimental built-in assemblers; LLVM calls them object writers[1]. > it looks like much of the interconnection

Hello All, Some people thought about a n LLVM wiki. Is there some alreadly? I wish it would be linked from LLVM.org site. Here are a few questions which I would like to be answered (preferably on a Wiki, to possibly participate): assuming that LLVM (latest from CVS) was configure-d with ./configure '--ENABLE-TARGETS=HOST-ONLY' '--WITH-GNU-LD' My main (currently platonic - ie

Right now, on X86, creating multiple ExecutionEngines in the same process causes an assertion. If it's supposed to always be a singleton, should there be a way to get the process's ExecutionEngine instance? This would, among other things, allow "lli" to execute bitcode that itself uses the ExecutionEngine.