[LLVMdev] Inline hint for methods defined in-class

[Hal Finkel]

----- Original Message -----
> From: "David Chisnall" <David.Chisnall at cl.cam.ac.uk>
> To: "Xinliang David Li" <xinliangli at gmail.com>
> Cc: "Xinliang David Li" <davidxl at google.com>, cfe-commits at cs.uiuc.edu, "List" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, July 9, 2015 3:09:30 AM
> Subject: Re: [LLVMdev] Inline hint for methods defined in-class
> 
> On 9 Jul 2015, at 08:00, Xinliang David Li <xinliangli at gmail.com>
> wrote:
> > 
> > You need to be more specific on why the regression is problematic
> > (and more so than missed opportunities).  Text size increase
> > (shared and much smaller than heap) is usually not a big issue
> > except for tiny devices which is likely to use Os/Oz in the build.
> > For servers, there are are simple rules to compare cpu vs ram
> > resource cost.
> 
> Text size increase also means more TLB and i-cache misses.

This is not necessarily true, and may not even generally be true. It certainly could be true under realistic circumstances, but if the inlining is effective, even if the number of cache lines or pages of all potentially-hot regions increases, that does not necessarily imply that the number of number of cache lines or TLB entries demanded in a generic small time window increases. In fact, in should decrease, because the code in any given hot region is more localized.

There are, of course, many factors here, and I agree that the trade-offs can be subtle, but I don't think we can try to do any kind of whole-system-workload optimization here without substantially more information. We don't have any idea what the cost function is, and in fact, it may be so different on different systems that we can't, as a community, really account for any of them.

 -Hal

>  We’ve
> observed that single-program benchmarks show this quite poorly, but
> the aggregate increase in i-cache and TLB pressure across the entire
> system can degrade performance overall on a typical desktop workload
> (not so relevant for single-application servers, but very relevant
> for server VMs).
> 
> I believe some folks at Apple did a more systematic analysis of this,
> but I don’t know if their detailed results are public.
> 
> David
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory