
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>Hi Arthur,<br></div><div><br></div><div>Thanks for following up!<br></div><div><br></div><div>We decided to pin the failing test (divergent-unswitch.ll) to the old pass manager for now, so this is no longer a blocker for flipping the bit in opt.<br></div><div><a target="_blank" href="https://reviews.llvm.org/D95051">https://reviews.llvm.org/D95051</a></div><div><br></div><div>The loop-unswitch transform needs divergence analysis to ensure that loops with a divergent conditions are not transformed. This is a correctness issue, which means that the lack of a DA makes loop-unswitching in the NPM unsafe for AMDGPU or any other target that cares about divergence. For now, I've filed a bug to track this: <a href="https://bugs.llvm.org/show_bug.cgi?id=48819" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=48819</a><br></div><div><br></div><div>I am currently attempting to make the new divergence analysis available on the new pass manager.<br></div><div><br></div><div>Sameer.<br></div><div><br></div><div class="zmail_extra" data-zbluepencil-ignore="true" style=""><div><br></div><div id="Zm-_Id_-Sgn1">---- On Tue, 19 Jan 2021 23:01:01 +0530 <b>Arthur Eubanks <aeubanks@google.com></b> wrote ----<br></div><div><br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); padding-left: 6px; margin: 0px 0px 0px 5px;"><div><div dir="ltr">Any update on this? This is the last known remaining NPM issue assuming <a href="https://reviews.llvm.org/D94153" target="_blank">https://reviews.llvm.org/D94153</a> is good to go.<br></div><div><br></div><div class="x_-398255667gmail_quote"><div dir="ltr" class="x_-398255667gmail_attr">On Thu, Jan 14, 2021 at 10:16 AM Arthur Eubanks <<a href="mailto:aeubanks@google.com" target="_blank">aeubanks@google.com</a>> wrote:<br></div><blockquote class="x_-398255667gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left: 1.0px solid rgb(204,204,204);padding-left: 1.0ex;"><div dir="ltr"><div class="x_-398255667gmail_quote"><blockquote class="x_-398255667gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left: 1.0px solid rgb(204,204,204);padding-left: 1.0ex;">Here's what I understood so far from a general eyeballing of the code:<br> <br> 1. Legacy DA is a wrapper around GPU DA. I could not find any direct use of GPU DA.<br> 2. It is likely that AMDGPU no longer "requires" Legacy DA. The advantage of the Legacy DA is that it can handle irreducible regions, but we usually convert them into loops for AMDGPU anyway. I don't know if we have reached a point where we don't care about legacy DA in this respect.<br> 3. StructurizeCFG under the new pass manager simply skips DA, and consequently cannot skip uniform regions. This essentially disables an optimization when moving to the new pass manager.<br> 4. Similarly, loop unswitching is an optimization and available in its simple form with the new pass manager. But I don't know for sure if it *must* skip loops with divergent values.<br> <br> So we (the AMDGPU folks) need to figure out how much is our dependency on any DA in the new pass manager. Besides the above optimizations, isn't it required for later target optimizations around SGPR usage? Is it possible to unblock the transition to the new pass manager, and then later restore these optimizations? Also, I am wondering if can focus on making only the new GPU DA available subject to #2 above. <br></blockquote><div><br></div><div>To be clear, currently the new PM switch only affects the optimization pipeline, which out of all the uses of Legacy DA only affects LoopUnswitch and StructurizeCFG. The other uses are in the codegen pipeline which isn't affected.<br></div><div> <br></div></div></div></blockquote></div></div></blockquote></div><div><br></div></div><br></body></html>