by Hoernchen » Wed May 15, 2013 4:12 pm
Well, 1) makes sense, but while i do appreciate the odd polyhedral optimization as much as the next guy as long as we're still working on basic stuff making external tools happy are still kind of at the bottom of the to-do list.
2) is a long way off, so of course eventually it needs to be updated, but at the moment chasing trunk means just running into new issues and fixing stuff that is not immediately revelant to the backend.
My versions of D149/D150 needed quite a few changes to work with my current version of llvm, you can't just apply the vanilla ones from the review website to the current master/trunk, and since they mess with a lot of internal stuff I'd expect them to keep breaking.
So in the end it depends on what you want to do, keep fixing stuff because of master which will pollute the history for little or no immediate gain, or work on the backend and do a proper merge/rebase some time in the future when the backend is ready for general consumption or merging becomes necessary. The latter would also make pulling and merging changes to the actual backend easier.