<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Joining in very late, but the tangent here has been interesting (if
rather OT for the original thread).<br>
<br>
I agree with Danny that we might want to take a close look at how we
model things like maythrow calls, no return, and other implicit
control flow. I'm not convinced that moving to a pure explicit
model is the right idea because we get a lot of gain in practice
from being able to reason about what are essentially a limited form
of extended basic blocks. I would welcome a design discussion about
this, preferably in person, but also don't want to block any current
(or future honestly) work on this until we have a reasonable firm
plan of action. <br>
<br>
One idea would be to explicitly acknowledge that our "basic blocks"
are actually "extended basic blocks" with internal exits due to
exception propagation, noreturn, and (recently) guards. I could see
a couple of implementation strategies here:<br>
1) Extend BasicBlock to explicitly track potential early exiting
instructions. This would probably have to be conservative so that
things like nothrow inference aren't required to update all callers
in one go.<br>
2) Conservative assume that BasicBlock has an unknown number of
early exiting instructions and write an analysis pass which answers
questions about where those early exits are. Any pass which does
code motion would require this analysis. (This is essentially the
principled version of our current hacks.)<br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 07/15/2016 06:57 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTUVUbemMJVyu64nwr6UasPROCch2u0zpiKz4jJj_MjTzQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a></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>
</blockquote>
<br>
</body>
</html>