Hi David, I would like to thank you for the due diligence in validating your code changes with the testing you've done and working through the reviewer feedback. The addition of the new features, performance improvements and defect fixes contained in this merge help advance the Open64 compiler greatly. Please go ahead with the merge from the open64-booster branch. Thanks.
Thanks for planning to checkin future changes in smaller chunks. That along with the increased number of gatekeepers should help expedite the checkin process. One last request: Could you update the Wiki page for the content of the next release with a summary of your major changes. I think you emailed this with your initial request a month ago. http://wiki.open64.net/index.php/ActiveDevelopment - Suneel On Fri, Aug 20, 2010 at 12:56 PM, David Coakley <dcoak...@gmail.com> wrote: > Hello all, > > Here is an update on the merge of the open64-booster branch into the > trunk that we started last month. > > We have completed all of the testing described in the check-in policy > posted at http://wiki.open64.net/index.php/CheckinPolicy. No > regressions were found and the results of some of the test suites were > improved. > > We also received review comments from some gatekeepers and external > reviewers, which I summarize here: > > o In the changes to the inlining heuristics, the reviewer pointed out > some dead code that had been added during development and testing. > The attached patch addresses the issue by removing that code. > > o In the review of the code generator changes, there was some > discussion about whether some new properties should be at the > "processor" level instead of the "isa" level. The developer felt that > these properties were easier to use at the "isa" level given the > current design, where only scheduling information is > processor-specific. Also, there were some formatting changes where > the developer made the formatting more consistent across the file -- > any remaining inconsistencies are unintentional and will be addressed > in a future update. > > o In the optimizer changes, the reviewer asked whether we had > considered doing the LOWER_SIMPLIFY_BIT_OP transformation earlier, in > preopt_phase instead of mainopt_phase. The developer replied that the > main reason to do the transformation while lowering was to avoid > complexity in the implementation. There were also some specific code > logic questions that were resolved. > > Thanks to the reviewers for their feedback! > > With the approval of one of the global gatekeepers, we would now like > to commit the merge changes to the trunk. > > Finally, I want to add that we understand the difficulty of making > large merges through the gatekeeper review system now in place. We're > taking steps that we hope will result in more individual commits and > smaller merges in the future. > > -David Coakley / AMD Open Source Compiler Engineering > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
