<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 8:32 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Handling unreachable code is annoying. I agree. However, its important to characterize how annoying. Most code is not unreachable, and we're (obviously) fine just bailing on such crazy code paths. So in practice the common cost is keeping a local set to detect cycles in the graph where we aren't expecting them. We are essentially always traversing a linked list representing this graph. Because these linked list nodes don't have any particular reason to have high locality, we have a cache-hostile traversal where we have to do primarily local and cache friendly book-keeping at each step to catch duplication. I suspect that this has a very small (but non-zero) impact on compile time.</blockquote></div><br>The other thing I meant to include here but forgot...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another reason why handling these cases has a tendency to be less expensive than you might expect is that we very often already have a set-like structure in place to remove *duplication*, and it is often very easy to re-use it to avoid cycles. So we won't be able to completely remove many of the sets you might expect to remove, they would just be narrower in scope due to not needing to handle cycles. My strong suspicion is that that narrower scope does not in fact translate to a significant efficiency gain.</div></div>