<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 9, 2012, at 1:50 PM, Jordan Rose wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mar 9, 2012, at 13:14, Anna Zaks wrote:<br><br><blockquote type="cite">[analyzer] Add support for NoRedundancy inlining mode.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We do not reanalyze a function, which has already been analyzed as an<br></blockquote><blockquote type="cite">inlined callee. As per PRELIMINARY testing, this gives over<br></blockquote><blockquote type="cite">50% run time reduction on some benchmarks without decreasing of the<br></blockquote><blockquote type="cite">number of bugs found.<br></blockquote><br><br>I might be missing something, but isn't this straight-up incorrect? Example:<br><br></div></blockquote><blockquote type="cite"><div>void doSomethingStupid(bool shouldCrash);<br><br>void analyzeMeFirst() {<br> doSomethingStupid(false);<br>}<br><br>void doSomethingStupid(bool shouldCrash) {<br> if (!shouldCrash) return;<br> void *p;<br> free(p); // this branch is pruned when doSomethingStupid is inlined<br>}<br><br><br></div></blockquote><blockquote type="cite"><div>(Even if this particular example works, I feel like there's a similar problem here somewhere.)<br><br></div></blockquote><br></div><div>Actually, when only considering this example (and the like), the optimization might actually be viewed as a desired feature for false positive suppression (assuming we always analyze externally available functions as top level functions). If all the callers of this function always pass in 'false', one might argue that we should not report the error. This is the appeal of inter-procedural <b>context sensitive</b> analyses. For example, we often report a buffer overflow with the CString checker under the assumption that the length parameter can be negative, when the programmer is sure it's always positive or is within a specific range.</div><div><br></div><div>On the other hand, my commit message might be somewhat misleading. This is an optimization which <b>can</b> result in loss of precision. Here is one example where we could loose precision:</div><div> - We are always analyzing the inlined function with a lower stack depth then that of the top-level function. Since we also bound the stack depth, the inlined function does not get as much inlining as the top level.</div><div><br></div><div>We still need to evaluate this optimization on a lot of code and see if that's the best option we have for improving performance under inlining. I'll be experimenting with other approaches as well (suggestions are welcome). Currently, analyzing with inlining can be an order of magnitude slower than without on some benchmarks, so we have to do something to bring that down.</div><div><br></div><div>Anna.</div><div><br></div></body></html>