similar to: Deleting function IR after codegen

Thanks for the pointer, it's always helpful to be able to see how another project solved similar problems. > On Mar 8, 2016, at 11:24 AM, Andy Ayers <andya at microsoft.com> wrote: > > FWIW, LLILC (https://github.com/dotnet/llilc) uses MCJIT with a custom memory manager to hold onto the binary bits and discard the rest. > > As far as I know it doesn't leak, though

Hi all After codegen for a given function, the IR should no longer be needed. In the AsmPrinter we convert from MI->MCInstr, and then we never go back and look at the IR during the MC layer. I’ve prototyped a simple pass which can be (optionally) scheduled to do just this. It is added at the end of addPassesToEmitFile. It is optional so that clang can continue to leak the IR with

Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow. Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows? -- lg > On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Larry, > > You're basically there, but you're hitting

Hi Larry, Thanks so much! This seems to do the trick. I would have spun my wheels for > a long time before discovering all of this, wow. No worries. :) I'll try to keep this in mind and make sure I address it in future Kaleidoscope tutorial chapters - these issues tripped me up the first time I encountered them too. Do I even want to know what additional chickens need to be sacrificed

>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) This is one is a bit tricky and hard to find. I spent quiet some time digging into MC and ORC JIT execution engines trying to find what makes them work. The problem is that this trick (LoadLibraryPermanently) happens inside of EngineBuilder, despite that the functionality belongs to a JIT engine itself, not to the builder. I

On Aug 18, 2010, at 10:24 AM, Reid Kleckner wrote: > You can free the machine code yourself by saying > EE->freeMachineCodeForFunction(F) . If you destroy the EE, it will > also free the machine code. Thanks, but unfortunately, this is exactly the opposite of what I want to do. I need to retain the machine code indefinitely, but I want to free all possible other resources that are

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have an app that's dynamically generating and JITing code, and will have many such cases in the course of its run. They need to be JITed separately, because I need to execute the first batch before I know what the second one will be. Of course, I *still* need to execute the first after the need for the second arises, so I need to retain the JITed machine code for all the functions I

Ah, that's helpful. I knew that I'd need to end up with PTX as text, not a true binary, but I would have figured that it would come out of MCJIT. Thanks for helping to steer me away from the wrong trail. OK, one more question: Can anybody clarify the pros and cons of generating the PTX through the standard LLVM distro, versus using the "libnvvm" that comes with the Cuda SDK?

There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). To generate PTX at run-time, you just set up a standard codegen pass manager like you would like an off-line compiler. The output will be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled

> On Mar 8, 2016, at 11:50 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > > I could attach a patch, but first i’d really like to know if anyone is fundamentally opposed to this. > > > Not necessarily. I think that any information that isn't being serialized in MI right now for a function could be as well. Definitely something for GlobalISel

Is there a succinct way I can get the full list of which optimization passes are applied, and in what order, for standard clang -O1, -O2, -O3? -- Larry Gritz lg at larrygritz.com

On Fri, Aug 20, 2010 at 12:39 PM, Larry Gritz <lg at larrygritz.com> wrote: > On Aug 18, 2010, at 10:24 AM, Reid Kleckner wrote: > >> You can free the machine code yourself by saying >> EE->freeMachineCodeForFunction(F) .  If you destroy the EE, it will >> also free the machine code. > > Thanks, but unfortunately, this is exactly the opposite of what I want

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

I have a whole slew of questions about optimization passes. Answers to any or all would be extremely helpful: How important are doInitialization/doFinalization? I can't detect any difference if I use them or not. Why does the function pass manager have doInitialization/doFinalization, but the global pass manager doesn't? If I am applying the function passes to many functions, do I

I have an app that uses LLVM API calls from C++ to generate IR and JIT it for x86 (for subsequent live execution). I'm still using the old JIT, for what it's worth. I want to modify it (for prototype/experimental purposes for now) to JIT PTX (into a big string buffer?). Docs are sketchy. I can wade through it and figure it out by trial and error, but would be so very happy if somebody

This is sounding rather like getLazyBitcodeModule is simply incompatible with MCJIT. Can anybody confirm that this is definitely the case? Is it by design, or by omission, or bug? Re your option #1 and #2 -- sorry for the newbie questions, but can you point me to docs or code examples for how the linking or object caching should be achieved? If I do either of these rather than seeding my

Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface

Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but