<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Personally, I don’t think these sort of back ports are a good idea. You are exposing differently shaped IR to the rest of the compiler, making it likely that you will expose many bugs in the rest of the compiler that (probably) would have been fixed in the ToT compiler but not in the old version.<div class=""><br class=""></div><div class="">I think it would be possible to back port the loop vectorizer with some effort, which means back porting the changes to TargetTransformInfo (with its dependencies on TargetLowering). The other dependencies should not have changed significantly - except maybe changes in names here and there. Changes to the loop vectorizer often where followed by changes to native code generation. You might run into issues with backends not supporting the vectorized IR well so your cost estimates are going to be off … </div><div class=""><br class=""></div><div class="">While certainly possible, I would not recommend it.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Sep 4, 2014, at 11:58 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><div class="">On Aug 14, 2014, at 7:51 PM, Richard Bagley <<a href="mailto:rickbagley@gmail.com" class="">rickbagley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal">I am seeking advice.</p><div class=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal">In your estimation, how difficult would it be to retrofit
LLVM</p><p class="MsoNormal">3.2 with this body of improvements to instruction scheduling
(and</p><p class="MsoNormal">optionally, the loop vectorization as well).</p></div></blockquote>By now you probably know the answer to this better than I do. But for the record:</div><div class="">MI scheduling infrastructure was largely in place by the 3.2 release. Since then there have been bug fixes, new heuristics, and more target hooks. Those improvements would probably be possible to back port if you’re really into that kind of thing.</div><div class=""><br class=""></div><div class="">I’m going to guess that loop vectorization would be harder to back port because much more work has been done in the past 3 releases. However, it is mostly a self-contained pass apart from the cost model, so might be possible, just a lot harder.</div><div class=""><br class=""></div><div class="">-Andy</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal">Would you have any suggestions for how best this might be</p><p class="MsoNormal">achieved, i.e. the scope of the code required? Has
anyone</p><p class="MsoNormal">attempted this kind of retrofit?</p></div></blockquote></div></div></div></blockquote></div></div></body></html>