On Dec 1, 2012, at 11:49 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote:> I definitely support this. > > In fact we were about to send a very similar proposal. The main difference I can see between this proposal and ours was that we named the attribute "noduplicate". > I graciously defer to James on the bikeshade color issue.Yes, this sort of functionality is useful. A few requests though: 1) please name it "noduplicate". "cloning" has other naming implications in llvm related to function bodies, but calls to a noduplicate function should not be duplicated in any way (e.g. tail duplication, loop unrolling, etc). 2) please have the llvm/Analysis/CodeMetrics.h code consider them to be unduplicatable (generalizing the containsIndirectBr bit). 3) Please change random parts of the compiler to use CodeMetrics, instead of scattering random checks for this attribute throughout the code. Anything duplicating code and not using CodeMetrics is just plain incorrect. -Chris
On Dec 2, 2012, at 10:11 PM, Chris Lattner <clattner at apple.com> wrote:> 3) Please change random parts of the compiler to use CodeMetrics, instead of scattering random checks for this attribute throughout the code. Anything duplicating code and not using CodeMetrics is just plain incorrect.One problem that we may run into when using CodeMetrics is compile time. In many cases we are looking for one particular trait and can exit as soon as we find it without having to scan the entire basic block or function. For example, the jump threading pass stops scanning additional instructions as soon as it passes the cost threshold. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121202/ee968c65/attachment.html>
On Sun, Dec 2, 2012 at 10:27 PM, Nadav Rotem <nrotem at apple.com> wrote:> > On Dec 2, 2012, at 10:11 PM, Chris Lattner <clattner at apple.com> wrote: > > 3) Please change random parts of the compiler to use CodeMetrics, instead > of scattering random checks for this attribute throughout the code. > Anything duplicating code and not using CodeMetrics is just plain > incorrect. > > > One problem that we may run into when using CodeMetrics is compile time. > In many cases we are looking for one particular trait and can exit as soon > as we find it without having to scan the entire basic block or function. > For example, the jump threading pass stops scanning additional > instructions as soon as it passes the cost threshold. >The inline cost analysis has similar problems, but compounded: we need to share the walk of instructions between cost computation and checking for incompatible patterns for inlining. A long standing todo on my list has been to factor code metrics into an API that inline cost analysis could actually use without interfering with the instruction visit pattern of that cost analysis. I haven't had time to really make progress, in part because I don't (yet) have any particularly good ideas.... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121202/e44fbe2e/attachment.html>
Hi, Thanks for the pointers. My patch now calls the attribute "noduplicate", and updates CodeMetrics to have another field: bool notDuplicatable; Which semantically is "containsIndirectBr || containsNoDuplicateInst". I didn't repurpose containsIndirectBr because I felt what I'm looking for is sufficiently different (indirectbr inhibits inlining, whereas noduplicate does not, if there is one call site). I still need to ensure InlineCost is correct; patch will be incoming tomorrow morning. All uses use CodeMetrics, except for JumpThreading because it has an early-exit mechanism as Nadav has explained. Cheers, James On Mon, 2012-12-03 at 06:27 +0000, Nadav Rotem wrote:> > On Dec 2, 2012, at 10:11 PM, Chris Lattner <clattner at apple.com> wrote: > > > 3) Please change random parts of the compiler to use CodeMetrics, > > instead of scattering random checks for this attribute throughout > > the code. Anything duplicating code and not using CodeMetrics is > > just plain incorrect. > > > One problem that we may run into when using CodeMetrics is compile > time. In many cases we are looking for one particular trait and can > exit as soon as we find it without having to scan the entire basic > block or function. For example, the jump threading pass stops > scanning additional instructions as soon as it passes the cost > threshold.