<div dir="ltr">Why does the new PM always make the target machine available? That seems inconsistent with our past directions. We go to all this trouble to make datalayout encapsulate everything IR-level passes need to know about the target (and TLI, I guess), we have the triple, metadata for wchar_t and all this stuff... and then we just let IR passes talk to the Target?<br><br>I think it would be a shame to lose the ability to run opt and clang -S -emit-llvm for a target without compiling in the target's code generator.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 13, 2019 at 6:08 PM Petr Hosek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I've been experimenting with enabling the new PM by default in our toolchain, using the <span style="color:rgb(0,0,0);white-space:pre-wrap">-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON option. However, when I do that, I see a lot (498) of failing tests.</span></div><div dir="ltr"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div dir="ltr"><span style="color:rgb(0,0,0);white-space:pre-wrap">I've filed PR</span><font color="#000000"><span style="white-space:pre-wrap">40724 for this issue and after a bit of investigating I also found out why these tests are failing. It boils down to two issues:</span></font></div><div dir="ltr"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div dir="ltr"><font color="#000000"><span style="white-space:pre-wrap"><div dir="ltr">1. Unlike the legacy pass manager, the new pass manager always makes the target machine available to passes so we have to always instantiate it even when we're only emitting bitcode, see <a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/BackendUtil.cpp#L952" target="_blank">https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/BackendUtil.cpp#L952</a>. This breaks when some targets tested by Clang don't match targets built by LLVM. In our case this is more prominent because we disable all targets that we don't support in our toolchain, but even in the default configuration you'll still see failures for experimental targets (e.g. RISC-V).</div><div dir="ltr"><br></div><div dir="ltr">2. Some Clang tests match the bitcode that's being emitted, but the emitted sometimes differs between the legacy and new pass manager.</div><div dir="ltr"><br></div><div>Has anyone already been thinking on how to handle these issues?</div><div><br></div><div>For the first one, the obvious solution is to mark all target-specific tests with appropriate `REQUIRES: <target>-registered-target` conditions. The downside is that we're going to loose coverage for some of the tests that are being run today with the legacy pass manager even when the target is disabled, but we're already seem to be using these conditions in many Clang tests so maybe it's not a big problem.</div><div><br></div><div>For the second issue, we could set a new feature config in lit whenever new PM is enabled (.e.g experimental-new-pm) and then either mark the broken tests as unsupported under new PM or provide two different bitcode versions to match against for legacy and new PM. It's probably easiest to start by disabling the failing tests first and then try and update all of them to make them work under new PM.</div><div><br></div><div>Do you have any opinion on this or other ideas/suggestions?</div></span></font></div></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>