[cfe-commits] r157483 - in /cfe/trunk: lib/CodeGen/CGCall.cpp test/CodeGen/alloc_size.c

[Evan Cheng]

On May 29, 2012, at 10:09 AM, Chandler Carruth wrote:

> I don't really disagree with either your or Evan's meta points. =] I agree something in this form *should* go into the tree.
> 
> On Fri, May 25, 2012 at 6:14 PM, Chris Lattner <clattner at apple.com> wrote:
> I definitely want this designed and implemented in the right way.
> 
> 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.

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...

> 
> 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.

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.

> 
> -Chandler
> 
> [*] 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....

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.

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120529/3ef5736b/attachment.html>