
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Chandler,<div><br><div><div>On Sep 29, 2014, at 6:05 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 4:28 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">AVX2 is still in-flight.</blockquote></div><br>AVX2 is pretty much done.</div><div class="gmail_extra"><br></div><div class="gmail_extra">All of the AVX and AVX2 lowering has now been heavily fuzz tested (a few million test cases and counting). I believe it is correct.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I've added the basic framework for AVX-512. Nothing interesting is implemented there, mostly because I think there are still very big unanswered questions about how AVX-512 should work. For example, it would be good to lower with index-destructive vs. table-destructive shuffles based on # of uses, but that isn't really possible today. Even better would be to actually respect any loop structure or other invariant properties.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There are still plenty of performance gains to be had in AVX or AVX2 (broadcast support, work to combine away intermediate shuffling such as can be seen in the v32i8 test cases with interleaved unpacks, etc. etc.</div><div class="gmail_extra"><br></div><div class="gmail_extra">However, I think essentially all of the test cases (other than broadcast and shift test cases) have been fixed. I'd really like to enable this and let folks submit patches for the few remaining cases that impact them significantly.</div></div></blockquote><div><br></div><div>Sounds good to me.</div><div>Just keep the old path until we are done with the triage of regressions.</div><div>Indeed, with r218454, I am seeing few regressions (working on test cases), but I do not think those should hold up on your big refactoring.</div><div><br></div><div>Thanks for all your work.</div><div>-Quentin</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">As far as I can tell, the new code paths offer very significant advantages for hardware folks have today with only a few downsides. While they are less implemented for AVX-512 than the current code, I don't really think that should be the priority.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Are there any remaining objections?</div><div class="gmail_extra">-Chandler</div></div>

</blockquote></div><br></div></body></html>