similar to: [LLVMdev] Inline hints for *compiler clients*

On Wed, 15 Mar 2006, Vikram S. Adve wrote: > [I've changed the subject to make this a new thread.] > > While all of this makes sense to me, note that Markus and John were asking > about different situations. Markus was asking about user-written source > code. John was asking about a compiler pass or tool written by a compiler > developer, not a user. > > These

On Mar 15, 2006, at 10:04 AM, Chris Lattner wrote: > On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> [I've changed the subject to make this a new thread.] >> >> While all of this makes sense to me, note that Markus and John >> were asking about different situations. Markus was asking about >> user-written source code. John was asking about a compiler pass

On Mar 15, 2006, at 11:15 AM, Chris Lattner wrote: > On Wed, 15 Mar 2006, Vikram S. Adve wrote: >>> Why can't the compiler pass just call InlineFunction(CallSite) on >>> the callsite it wants inlined? The only way that can fail is if >>> LLVM cannot ever inline the call (e.g. it uses varargs). > >> In some cases, that would be fine. But in other

Vikram S. Adve wrote: Hmmm. It seems the discussion has grown a little bit larger than I had intended. :) Basically what I think would be useful is an option to the inliner that gives it a list of functions to skip when inlining. My argument for this is that we have several transformations now that search for calls to specific functions; if those functions are inlined, the transform pass

On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> Why can't the compiler pass just call InlineFunction(CallSite) on the >> callsite it wants inlined? The only way that can fail is if LLVM cannot >> ever inline the call (e.g. it uses varargs). > In some cases, that would be fine. But in other cases: > (1) It cannot "un-inline" any function that was previously

On Mar 6, 2006, at 4:05 PM, Chris Lattner wrote: > On Mon, 6 Mar 2006, John Criswell wrote: >> I was wondering if there is a standard way of specifying a list of >> functions that *should not* be inlined by the -inline pass. > > Nope, but you could hack something into gccas/gccld if you want. > Of course, you can disable inlining completely with the -disable- >

On Tue, 7 Mar 2006, Vikram S. Adve wrote: > Changing the heuristics directly would have to be a custom change (i.e., > couldn't be checked in). Is there a way for a client pass or tool to > influence the heuristics? If not, does it make sense to add such a > mechanism? To be clear, I'll restate my position here, then follow up with more specifics of such a mechanism to

On Wed, 15 Mar 2006, John Criswell wrote: > Vikram S. Adve wrote: > Basically what I think would be useful is an option to the inliner that gives > it a list of functions to skip when inlining. My argument for this is that > we have several transformations now that search for calls to specific > functions; if those functions are inlined, the transform pass can no longer >

On Mar 15, 2006, at 3:27 PM, John Criswell wrote: > Vikram S. Adve wrote: > > Hmmm. It seems the discussion has grown a little bit larger than I > had intended. > :) > > Basically what I think would be useful is an option to the inliner > that gives it a list of functions to skip when inlining. My > argument for this is that we have several transformations now

Vikram S. Adve wrote: > On Feb 22, 2007, at 10:21 AM, Robert L. Bocchino Jr. wrote: > > >>I glanced at the code again, and it looks like I use DSA to (1) >>construct the call graph and (2) identify things that would be >>unsafe to put on the stack, such as arrays, cyclic data structures, >>and allocations with escaping references. Right now these parts

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

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

I would like to start prototyping changes towards profile guided inlining. Before doing so, I wanted to get feedback from the community on the appropriate approach. I'm going to layout a strawman proposal, but I'm open to other ideas on how to approach the problem. Depending on what approach we settle on, I *may* be able to commit resources to actually implement this in the near

On Feb 22, 2007, at 1:54 PM, Nick Lewycky wrote: > Vikram S. Adve wrote: >> On Feb 22, 2007, at 10:21 AM, Robert L. Bocchino Jr. wrote: >> >> >>> I glanced at the code again, and it looks like I use DSA to (1) >>> construct the call graph and (2) identify things that would be >>> unsafe to put on the stack, such as arrays, cyclic data structures,

On Fri, Dec 12, 2014 at 1:59 PM, Diego Novillo <dnovillo at google.com> wrote: > On 12/12/14 15:56, Adve, Vikram Sadanand wrote: >> >> I've been asked how LTO in LLVM compares to equivalent capabilities >> in GCC. How do the two compare in terms of scalability? And >> robustness for large applications? > > > Neither GCC nor LLVM can handle our

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

RFC: Inlining Report Motivation Making good inlining choices while optimizing an application is often key to achieving optimal performance. While the compiler's default inlining heuristics sometimes provide great out-of-box results, optimal performance is sometimes achieved only after varying the settings of certain compiler options related to inlining or adding "always_inline" or

On Apr 26, 2006, at 10:45 AM, Tom Tromey wrote: >>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: > > Vikram> Either way, one issue that you will have to deal with is > preserving > Vikram> the behavior of Java exceptions (assuming you care about > that). LLVM > Vikram> does not preserve the order of potentially

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

Dear all, Is anyone aware of any implementation of an inter procedural slicing algorithm for LLVM? I am mostly interested in a static algorithm but a dynamic one can be helpful too. Thanks, Silviu Ganceanu Research Student, Ecole Polytechique Federale de Luasanne -------------- next part -------------- An HTML attachment was scrubbed... URL: