similar to: [LLVMdev] the PartialSpecialization pass (was Re: Is there a "callback optimization"?)

Applied, with minor changes: 1. deleted[std:distance(as, ai)] creates a map entry (with a null value if the operator[] is not the left-hand-side of an assignment statement) if one doesn't already exist. deleted->find returns deleted.end() if the entry doesn't exist and doesn't change the map. 2. Included a comment to make it easy to find the spot where the callsite is checked

Good evening, Kenneth. Thank you to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were

It should be relatively simple to write a pass that turns each call that has constant argument(s) into a call to specialized version of the callee. To devirtualize C++ calls it needs to be smarter, since the argument is not a constant, but a pointer to a struct that points to a constant. However, the trick here is 1) Knowing when to perform specialization. If the call was not inlined the function

When I used -std-compile-opts -disable-inlining, my transform didn't happen. I think in your test, the inline of UseCallback into foo automatically made the function pointer into a constant, which turned it into a direct call that was then inlined. If UseCallback is too big to inline and uses the callback parameter inside a loop, this transform is potentially valuable, particularly if

On Fri, Jun 4, 2010 at 1:35 PM, Eugene Toder <eltoder at gmail.com> wrote: > It should be relatively simple to write a pass that turns each call > that has constant argument(s) into a call to specialized version of > the callee. To devirtualize C++ calls it needs to be smarter, since > the argument is not a constant, but a pointer to a struct that points > to a constant.

Hi, > 1) Knowing when to perform specialization. If the call was not inlined > the function is probably big. Getting this wrong will generate *a lot* > of code for very small (if not negative) speed gain. Could you elaborate why just having (lots of) more code in the final executable will incur a performance _penalty_? I was thinking of something similiar, but for type-specializations of

On Thu, Jul 16, 2009 at 9:10 AM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > 1. Which ones?  I know that Windows uses it for the "this" pointer. The internal fastcc convention and the Windows fastcall convention off the top of my head. > Anyway, unless the callee is required to preserve it in a given > calling convention, that doesn't preclude us using it for

Hi, I browsed the LLVM inliner implementation, and it seems there is room for improvement. (I have not read it too carefully, so correct me if what I observed is wrong). First the good side of the inliner -- the function level summary and inline cost estimation is more elaborate and complete than gcc. For instance, it considers callsite arguments and the effects of optimization enabled by

Hi all, I'm attempting to use LLVM for run-time code specialization, but I'm facing a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and over again. So I was hoping that by first creating unspecialized LLVM

1. Which ones? I know that Windows uses it for the "this" pointer. Anyway, unless the callee is required to preserve it in a given calling convention, that doesn't preclude us using it for a *return* value. It would be checked after calls return, and wouldn't affect the use of the register for passing values in before the call is made. The callee would set it right before

Hello LLVMers, I'm putting together some (extensive) experiments with using a genetic algorithm to construct sets of optimization passes that are as close as optimal in a number of ways, e.g. compilation time, execution time, code size, ... I've figured out which LLVM tools I should use for this (llvm-gcc to obtain bitcode, opt to optimize, llc to obtain assembly, ...), and I'm now

I don't think there is any infrastructure for this kind of specialization. The closest thing I can think of is the profile-guided optimization stuff that Andreas Neufstifter has worked on. Because compilation and optimization with LLVM is expensive, our approach with Unladen Swallow has been to try to wait longer to generate specialized code, so we don't have to recompile. If memory

On 8/4/2017 2:06 PM, Daniel Berlin wrote: > A few notes: > I'm a bit surprised IPO copy/constant propagation doesn't get this > case, but i didn't look if the lattice supports variables. > In particular, in your example, given no other call sites, it should > eliminate the dead code. > (In a real program, it may require cloning). In the actual program

On Tue, Nov 23, 2010 at 8:07 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Hi, I browsed the LLVM inliner implementation, and it seems there is room > for improvement.  (I have not read it too carefully, so correct me if what I > observed is wrong). > First the good side of the inliner -- the function level summary and inline > cost estimation is more elaborate and

By that I mean an optimization pass (or a combination of them) that turns: void useCallback(void (*callbackfn)()) { // Do something callbackfn(); // Do something else } void myCallback() { // Respond one way } void myOtherCallback() { // Respond another way } void foo() { useCallback(myCallback); useCallback(myOtherCallback); } into: // Keep the original; it'll get removed // by other

Dear Kenneth, May I ask you if you are implementing your search within ctuning framework: ctuning.org/ctuning-cc? The thing is that I use it since some time for my thesis to optimize code size and compilation time and run time with GCC though they are not using genetic algorithms but some slower hybrid of random exploration and than AI with some fronteer detection. Since recent version can be

Xinliang David Li wrote: > Hi, I browsed the LLVM inliner implementation, and it seems there is > room for improvement. (I have not read it too carefully, so correct me > if what I observed is wrong). > > First the good side of the inliner -- the function level summary and > inline cost estimation is more elaborate and complete than gcc. For > instance, it considers callsite

On Jul 6, 2010, at 10:09 AM, Manuel Llosa wrote: > Dear Kenneth, May I ask you if you are implementing your search within > ctuning framework: ctuning.org/ctuning-cc? No, I'm not. I've built my own framework, and since I don't have any experience with the ctuning framework, I don't intend to start using that. There's little gain in it for me. > The thing is that I

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance

On Nov 23, 2010, at 5:07 PM, Xinliang David Li wrote: > Hi, I browsed the LLVM inliner implementation, and it seems there is room for improvement. (I have not read it too carefully, so correct me if what I observed is wrong). > > First the good side of the inliner -- the function level summary and inline cost estimation is more elaborate and complete than gcc. For instance, it considers