similar to: [LLVMdev] Optimization pass questions

On Aug 11, 2010, at 4:55 PM, Larry Gritz wrote: > 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?

Larry, On Wed, Aug 11, 2010 at 4:55 PM, Larry Gritz <lg at larrygritz.com> wrote: > I have a whole slew of questions about optimization passes. Answers to any > or all would be extremely helpful: > > How important are doInitialization/doFinalization? Most of the passes do not use them. > I can't detect any difference if I use them or not. Say, if you are writing

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

On Aug 11, 2010, at 5:57 PM, Tanya Lattner wrote: > Have you read this document? > http://llvm.org/docs/WritingAnLLVMPass.html#passtype Yes, but I didn't find it as instructive as I'd hoped. The only two examples of pass sets I can find are the Kaleidoscope tutorial and StandardPasses.h (corresponding, I assume, to what llvm-gcc does). Just looking at the two of these, some

On Fri, 12 Nov 2010 17:42:57, Daniel Dunbar <daniel at zuster.org> wrote: > If you are a "sophisticated" JIT user and are using either internal > APIs (either by integrating with LLVM, or by other C++ tricks), or are > using obscure or poorly documented public APIs (e.g., why is > runJITOnFunction exposed?) please make me aware of it! Hi, Daniel! We

On 11.05.2012, at 21:17, Larry Gritz wrote: > I have a DSL that creates LLVM IR on the fly and JITs to x86 at runtime. (https://github.com/imageworks/OpenShadingLanguage) > > Primarily, we have a main app that uses the library that implements our DSL. But we have other usage cases in which we have written dynamically-loaded plugins to 3rd party apps that we don't control, and our

I have a DSL that creates LLVM IR on the fly and JITs to x86 at runtime. (https://github.com/imageworks/OpenShadingLanguage) Primarily, we have a main app that uses the library that implements our DSL. But we have other usage cases in which we have written dynamically-loaded plugins to 3rd party apps that we don't control, and our plugins use our language, which necessitates linking to

Another usage case, slightly different than your #1: 6. Dynamic code generation (not interactive with respect to the source code) - app generates code IR which is compiled as needed for execution (important difference: no waiting for a typing human in the loop, so very different expectations about responsiveness and bottlenecks) - compilation speed IS critical (because many such

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

Hello All, I have two questions, one more of an implementation question, the other more a design question. First: I noticed that if one moves the FPPassManager::doInitialization(Module) call from FPPassManager::runOnModule to MPPassManager::runOnModule (which is the new location I am aiming for to avoid the need for a doInitialization/doFinalization outside of the run methods, as preferred by

Hello All, I have two questions, one more of an implementation question, the other more a design question. First: I noticed that if one moves the FPPassManager::doInitialization(Module) call from FPPassManager::runOnModule to MPPassManager::runOnModule (which is the new location I am aiming for to avoid the need for a doInitialization/doFinalization outside of the run methods, as preferred by

Hello Yiannis, I am not an expert on metadata or the CG information but one of the two has to happen: - Simply moving the deleter pass to a different spot - Changing the doFinalization of another pass (Printer?) to do the deleter pass job (this should work now because the doFinalization order is the reverse of the doInitialization order) Option 1 is a smaller change, option 2 will make the code

Hello Yiannis, I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to call the finishAssembly function. Right now the order that the doFinalization is called on passes is the reverse

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

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

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

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

Hi Pedro (et al.), On 02/14/2013 11:43 PM, Pedro Artigas wrote: > I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called.

On Tue, Aug 17, 2010 at 5:04 PM, Larry Gritz <lg at larrygritz.com> wrote: > On Aug 17, 2010, at 10:11 AM, Owen Anderson wrote: > >> In principle this ought to work, if you're careful.  Are you sure you're not generating code that calls into functions that got totally inlined away? > > How would I know? > >>  Are you running the Verifier pass at regular