
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 29, 2012, at 10:09 AM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I don't really disagree with either your or Evan's meta points. =] I agree something in this form *should* go into the tree.<br><br><div class="gmail_quote">On Fri, May 25, 2012 at 6:14 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I definitely want this designed and implemented in the right way.</blockquote></div><br><div>This is the key. I never saw a really good, complete design discussion on the mailing lists. Instead, there was a very fragmented discussion spanning several commit logs, with a bit of confusion. The questions asked on the review of alloc_size and other parts of the system were never really answered, and the discussion didn't really reach a clear consensus on direction.</div></blockquote><div><br></div>I believe everyone agrees that the community as a whole should continues the discussion towards a consensus. For specific implementation details such as the alloc_size intrinsic, I have no doubt that will happen. However...</div><div><br><blockquote type="cite">

<div><br></div><div>Kostya and others have tried to consolidate this discussion some, but I'm looking for a bit more focus on discussing the design in the open, and getting some consensus. I'm fine if commits* are flying concurrently in order to keep making progress, but the design side of the discussion can't be neglected. As examples, I would point to Bill's work on metadata or exception handling, or Caitlin and Delesley's work on the thread-safety attributes -- regardless of the desirability of these new features, I think that they did a great job of proposing the design and engaging the community in a discussion about the design so that everyone knew what was going on and why.</div></blockquote><div><br></div>This is where I have issues with the tone of the discussion on the codegen side. I think there is a fundamental disagreement about the scope of the project. Nuno and I are not looking for a solution for all the memory safety systems. I also don't think some hard open questions, such as how other classes of undefined behavior interact with -fbounds-checking, should prevent progress from being made. As far as I can tell what Nuno has implemented so far can be easily modified for whatever solution the community comes up in the future.</div><div><br><blockquote type="cite">

<div><br></div><div>-Chandler</div><div><br></div><div>[*] The commits should still get proper review. I think this commit should probably have had pre-commit review as it doesn't seem "obvious", it isn't to a nicely isolated optimization pass like BoundsChecking, and doesn't seem to have had a blanket OK from a code-owner for CodeGen....</div>

</blockquote></div><br><div>I agree Nuno may have jumped the gun a bit here. It looks like the discussion is still ongoing and we will make sure future commits address the reviewers concerns.</div><div><br></div><div>Evan</div></body></html>