similar to: [LLVMdev] ModuleProvider materializeFunction

On Jul 4, 2009, at 5:59 AM, Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in > hopes of determining how to properly utilize this function but from > my explorations I gather it's just a hook which is called by the JIT > system and I would mostly have to do the work myself. ModuleProvider is a very simple concept. You can either load

Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. > > What is the preferred way to inject a llvm:Function which contains basic blocks into the Module +

Thanks for the reply. I actually managed to resolve this problem mostly to my satisfaction. I suspect based on your description of materializeFunction I may be best served by subclassing the ModuleProvider to do what I want. Thanks again. --- On Mon, 7/6/09, Chris Lattner <clattner at apple.com> wrote: > From: Chris Lattner <clattner at apple.com> > Subject: Re: [LLVMdev]

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Hi, I'm seeing rather high memory usage from LLVM and I'd like to track down what I'm doing to cause it. My application is a simple web application server that compiles web pages with embedded script to bitcode and compiles them with the JIT on demand. I've taken tools/lli.cpp as a starting point and extended it to load additional modules. However, if I load successive pages and

On Thu, Feb 11, 2010 at 6:53 PM, James Williams <junk at giantblob.com> wrote: > Hi, > > I'm seeing rather high memory usage from LLVM and I'd like to track down > what I'm doing to cause it. My application is a simple web application > server that compiles web pages with embedded script to bitcode and compiles > them with the JIT on demand. I've taken

Hi, I am trying to generate LLVM bytecode using CLANG and I ran into the following problem. If I run clang with the -emit-llvm option and then try to get a textual representation of the output using llvm-dis, the latter crashes because of a failed assertion in BitCodeReader.cpp, mentioning a "Type mismatch in value table" (the exact error message is appended at the end of this email).

On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote: > > ----- "Evan Cheng" <evan.cheng at apple.com> wrote: > >> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: >> >>> Evan, >>> So, if I understand you correctly, the design you have in mind is >>> to: create a PassManager, pass it to the JIT on construction, and >>>

Hi all, As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 I took a step towards that by proposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the

That was likely type information and should mostly be fixed up. It's still not lazily loaded, but is going to be ridiculously smaller now. -eric On Fri Jan 10 2014 at 12:11:52 AM, Sean Silva <chisophugis at gmail.com> wrote: > This Summer I was working on LTO and Rafael mentioned to me that debug > info is not lazy loaded, which was the cause for the insane resource usage > I

On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for > ThinLTO + vcall CFI" I would like to introduce the ability for bitcode > files to contain multiple

----- "Evan Cheng" <evan.cheng at apple.com> wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function

Adrian may have handled this recently? On Jan 13, 2014 3:34 PM, "Manman Ren" <manman.ren at gmail.com> wrote: > I briefly looked at the bit code files and some types are not uniqued, > here is one example: > !3903 = metadata !{i32 786454, metadata !3904, null, metadata !"int64_t", > i32 198, i64 0, i64 0, i64 0, i32 0, metadata !2258} ; [ DW_TAG_typedef ]

I'm having a problem with MCJIT (in LLVM 3.3 and 3.4), in which it's not resolving symbol mangling in a precompiled bitcode in the same way as old JIT. It's possible that it's just my misunderstanding. Maybe somebody can spot my problem, or identify it as an MCJIT bug. Here's my situation, in a nutshell: * I am assembling IR and JITing in my app. The IR may potentially make

Hi, For the first problem, try clang -S -emit-llvm test.c -o test.ll you should get the llvm IR and you don't need to use llvm-dis. Although I have tried your example with the exact commands and source code you posted and it worked just fine for me. I also use clang and LLVM 2.8 compiled from sources. For the second problem, suppress -emit-llvm, since you want the executable, not an object

Hi all, I'm trying to reduce the startup time for my JIT, but I'm running into the problem that the majority of the time is spent loading the bitcode for my standard library, and I suspect it's due to debug info. My stdlib is currently about 2kloc in a number of C++ files; I compile them with clang -g -emit-llvm, then link them together with llvm-link, call opt -O3 on it, and arrive

On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: > On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> > >> > >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter

First, I'm not sure if deleting the ExecutionEngine is all I need to clean-up... so I started with a minimal test just to check int main( int argc, char **argv ){ while( true ){ Module *M = new Module("M"); Function *F = cast<Function>(M->getOrInsertFunction("F", Type::Int32Ty, (Type*)0)); BasicBlock *BB = new

On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> As mentioned in my recent RFC entitled

> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 <https://reviews.llvm.org/D24786> I took a step