<br><br><div class="gmail_quote">On Thu, Oct 23, 2008 at 7:06 AM, Tanya Lattner <span dir="ltr"><<a href="mailto:lattner@apple.com">lattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Chris is 100% correct. We don't merge in patches at this point that are not regressions in llvm-test or dejanu checks from 2.3. I'll be detailing this in a release policy document for 2.5. Because there is some confusion on the issue, I've merged this into 2.4, but this would not normally meet our criteria.<div>
<br></div><div>We have to draw the line at some point or we would never get out a release. With every patch we merge in there is risk associated with it and requires a full run of the test suite on all the platforms we support. We try very hard to have high quality releases, so you can understand why we are conservative.</div>
<div><br></div><font color="#888888"><div>-Tanya</div></font><div><div></div><div class="Wj3C7c"><div><br><div><div>On Oct 22, 2008, at 10:40 AM, Tomas Lindquist Olsen wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">
On Wed, Oct 22, 2008 at 7:23 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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div><div></div><div><br><div><div>On Oct 22, 2008, at 1:15 AM, Tomas Lindquist Olsen wrote:</div><br><blockquote type="cite">On Tue, Oct 21, 2008 at 10:00 PM, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com" target="_blank">gohman@apple.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Author: djg<br> Date: Tue Oct 21 15:00:42 2008<br> New Revision: 57925<br>
<br> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=57925&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=57925&view=rev</a><br> Log:<br> Fix SelectionDAGBuild lowering of Select instructions to<br>
handle first-class aggregate values. Also, fix a bug in<br> the Ret handling for empty aggregates.<br> <br> Added:<br> llvm/trunk/test/CodeGen/X86/pr2924.ll<br> Modified:<br> llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp<br>
<br> </blockquote></div><br>Any chance this will make it into the 2.4 branch ?</blockquote></div><br></div></div><div>If you have an example of C code that worked with llvm-gcc in 2.3 but that fails with llvm-gcc in 2.4, then it would be a regression and yes we would want to pull it in. Otherwise unfortunately we shouldn't pull it in.</div>
<div><br></div><font color="#888888"><div>-Chris</div></font></div><br>_______________________________________________<br> llvm-commits mailing list<br> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br> <br></blockquote></div><br>Ok :(<br><br>I don't have llvm-gcc, this code is generated by my D compiler.<br>
<br>Using first class aggregates only started working after this fix (at least when doing optimizations, which is what produces the select inst)<br> <br>Sounds like we won't be able to support the 2.4 release. Oh well...<br>
<br>If I do find some time for it, what kind of C/C++ code would I write to generate something that produces first class aggregates ?<br> _______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br>First, thanx a lot for making the exception :)<br>About the reason that I was asking for this in the first place, I dont't think I was clear enough on why it was important....<br><br>The thing is we don't generate the select, it's produced by one of the LLVM optimization passes (it was fixed so fast I never found out which one, rather just updated llvm). Our unoptimized LLVM code codegen'd as it should, but after optimization the select would be there and break codegen, so we could have lived without it, if we could live without optimizations...<br>
<br>The other option would have been to revert my changes that introduced these FCA's, but they're needed as part of my work on following the D calling convention / ABI.<br><br>I hope this is a bit more clear...<br>
<br>I can fully understand the reasons for not merging in every fix, from working on our own compiler, I've seen how a seemingly small change can break lots of code that you would never have thought was even affected.<br>
<br>Thanx again for merging it in.<br>-Tomas<br>