[cfe-dev] Clang tests with new pass manager

[Reid Kleckner via cfe-dev]

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?

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.

On Wed, Feb 13, 2019 at 6:08 PM Petr Hosek via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I've been experimenting with enabling the new PM by default in our
> toolchain, using the -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON option.
> However, when I do that, I see a lot (498) of failing tests.
>
> I've filed PR40724 for this issue and after a bit of investigating I also
> found out why these tests are failing. It boils down to two issues:
>
> 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
> https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/BackendUtil.cpp#L952.
> 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).
>
> 2. Some Clang tests match the bitcode that's being emitted, but the
> emitted sometimes differs between the legacy and new pass manager.
>
> Has anyone already been thinking on how to handle these issues?
>
> 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.
>
> 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.
>
> Do you have any opinion on this or other ideas/suggestions?
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190214/269640dc/attachment.html>