<div dir="ltr">On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <span dir="ltr"><<a href="mailto:dan433584@gmail.com" target="_blank" class="cremed">dan433584@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">To all, I'm moving on and accepting what appears to be the consensus of the list, for now.<br></div>
</blockquote><div><br></div><div style>I want to point out something about this direction that hasn't really come up, but I think deserves some better discussion. I don't think it should be the basis of a decision one way or the other, its more a consequence of the decision.</div>
<div style><br></div><div style>At the IR level, we have some great infrastructure that doesn't exist at the MI level:</div><div style><br></div><div style>- The pass management tools.</div><div style>- A verifier that can be run before and after any pass to check the basic invariants.</div>
<div style>- The ability to serialize and deserialize to/from a human understandable (and authorable) form.</div><div style><br></div><div style>I think before we invest in *significantly* more complexity and logic in the MI layer of the optimizer, we will need it to have these three things. Without them, the work will be considerably harder, and we will continue to be unable to do fine grained testing during the development of new features. We might not need all of the capabilities we have in the IR, but I think we'll need at least those used to orchestrate fine grained testing and validation.</div>
<div style><br></div><div style>Of course, adding these to MI would be of great benefit to any number of other aspects of LLVM's development. I am *not* arguing we should eschew MI because it lacks these things. I just want people to understand that part of the cost of deciding that MI is the right layer for this is needing to invest in these pieces of the MI layer.</div>
</div></div></div>