<div class="gmail_quote">On Mon, Sep 12, 2011 at 11:28 AM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Sep 12, 2011, at 2:22 AM, Chandler Carruth wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
I think this patch is a really useful improvement in accuracy, but it does add some non-trivial overhead to the process of adding implicit destructors into the CFG for automatic variables.. Does it seem acceptable? I don't see particularly cleaner ways of doing this... =/</div>
</span></blockquote><div><br></div></div><div>I think this is a reasonable approach.</div><div><br></div><div>By non-trivial overhead, are you talking about something that is actually measurable in terms of -fsyntax-only time?  Do you have any numbers?</div>
</div></div></blockquote><div><br></div><div>Not yet, easy to get though. The overhead is the SmallVector<..., 10> which I use to reverse the VarDecl*s prior to appending them. That *shouldn't* have an observable impact, but I'll measure it. =] I just wanted to see if I was on the right track at all.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><div><br></div><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
<br></div><div>If this patch is OK, or after any performance tuning you'd like to see here, I think I also better understand the FIXME in the analysis file. Do you actually want to switch the CFG to have *no* successors for blocks which contain a no-return element?<span> </span></div>
</span></blockquote></div></div><br><div>No at all.  That's definitely not the invariant we are going for.  We want all blocks to be reverse-reachable from the exit block.  This is needed for servicing reverse dataflow analyses.</div>
</div></blockquote></div><br><div>Cool, it seemed a bit odd to me as well. I'll follow up on this point on your other email.</div>