<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 5:25 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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"><span class=""><br><div><blockquote type="cite"><div>On Jul 15, 2016, at 4:48 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:</div><br><div><span style="font-family:arial,helvetica,sans-serif;font-size:13.333333015441895px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Why? A decision was made to give pointers types, and we've decided to change that. It is not clear to me that the decision to allow implicit early exits was, in retrospect, optimal. I think it is completely healthy for the project to reevaluate these kinds of decisions. We now have many years of experience, bug reports, and we should have a good ability to evaluate the compile-time impact of a potential change.</span></div></blockquote></div><div><br></div></span>Let me rephrase: It didn’t seem to me like the fundamental problem we were up against in this discussion, and it’s definitely very difficult to change given the burden it would place on intrinsics.<div><br></div></div></blockquote><div><br></div><div>Yes, this discussion has gone a bit off track, which i will apologize for.</div><div> </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>FWIW, for a long time I was a very strong proponent of explicit control flow because I like making it easy to reason about CFG transforms and code motion. But I gradually came around to realize it’s a legitimate design either way. In some ways it works well not to have a CFG edge for exits where it’s illegal to insert code.</div></div></div></blockquote><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> I think LLVM passes have also been biased toward algorithms that scale in the number of blocks.</div></div></div></blockquote><div>If this scaling is a design goal that's really interesting. Most of the memory opt and code motion algorithms i've worked on in LLVM are block/instruction-capped in the same way (and most have lower caps than GCC due to compile time impact on llvm).  </div><div>There certainly was a time when that wasn't true (i remember back in the day :P), but it's no longer true.</div><div><br></div><div>Of course, I don't actually think either design necessarily makes scaling easier or harder, that's just "the state of the world".</div><div><br></div><div><br></div></div></div></div>