I'm working on a new version of the patch. Another thing I wanted to ask about - do you prefer to have one giant patch that has everything, or a series of incremental patches? I can see advantages either way. Normally I would want to do this as a series of incremental patches, however this is a rather large project and it may take me quite a while before it's completely done. I don't doubt that I will need some assistance when it comes to the trickier parts (like the optimization aspects you mentioned.) So there's a risk involved in submitting the first one or two patches, because the final patch might not be ready in time for the next release. On the other hand, it will be a lot easier for others to assist if we go ahead and submit the initial work. On Mon, Jan 11, 2010 at 12:02 PM, Chris Lattner <clattner at apple.com> wrote:> > On Jan 11, 2010, at 11:10 AM, Talin wrote: > > > Quick question - should unions enforce that all member types are unique? > I realize that a union of { i32, i32 } doesn't make sense, but should the > code actually forbid this? > > Either way works for me. > > > As far as constants go, as long as the initializer is an exact match for > one of the member types, it should be no problem. > > Right, please propose a syntax and a class to use (ConstantUnion?) for it, > > -Chris-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100111/5af69ee8/attachment.html>
On Jan 11, 2010, at 4:30 PM, Talin wrote:> I'm working on a new version of the patch. > > Another thing I wanted to ask about - do you prefer to have one > giant patch that has everything, or a series of incremental patches? > I can see advantages either way.A series of incremental patches is strongly preferred, starting with LangRef.html.> Normally I would want to do this as a series of incremental patches, > however this is a rather large project and it may take me quite a > while before it's completely done. I don't doubt that I will need > some assistance when it comes to the trickier parts (like the > optimization aspects you mentioned.) So there's a risk involved in > submitting the first one or two patches, because the final patch > might not be ready in time for the next release. > > On the other hand, it will be a lot easier for others to assist if > we go ahead and submit the initial work.No problem, just submit it as you go. When the langref piece goes in, just say in it that this is an experimental feature in development. Thanks Talin, -Chris
Here is the LangRef part of the patch. On Tue, Jan 12, 2010 at 2:11 PM, Chris Lattner <clattner at apple.com> wrote:> > On Jan 11, 2010, at 4:30 PM, Talin wrote: > > I'm working on a new version of the patch. >> >> Another thing I wanted to ask about - do you prefer to have one giant >> patch that has everything, or a series of incremental patches? I can see >> advantages either way. >> > > A series of incremental patches is strongly preferred, starting with > LangRef.html. > > > Normally I would want to do this as a series of incremental patches, >> however this is a rather large project and it may take me quite a while >> before it's completely done. I don't doubt that I will need some assistance >> when it comes to the trickier parts (like the optimization aspects you >> mentioned.) So there's a risk involved in submitting the first one or two >> patches, because the final patch might not be ready in time for the next >> release. >> >> On the other hand, it will be a lot easier for others to assist if we go >> ahead and submit the initial work. >> > > No problem, just submit it as you go. When the langref piece goes in, just > say in it that this is an experimental feature in development. Thanks > Talin, > > -Chris > >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100112/de2f07ac/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: unionref.patch Type: application/octet-stream Size: 8332 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100112/de2f07ac/attachment.obj>