A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.llvm.org/pipermail/llvm-dev/2020-July/143410.html below:

[llvm-dev] [RFC] Introducing classes for the codegen driven by new pass manager

[llvm-dev] [RFC] Introducing classes for the codegen driven by new pass managerNicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 15 01:58:35 PDT 2020
On Tue, Jul 14, 2020 at 11:29 PM James Y Knight via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I'd just note that not every pass you can run with "opt" is actually part of the optimization pipeline. There are a few important IR-level passes that only run in the codegen pipeline, but are still nameable with opt to run individually for testing purposes. Switching over doesn't need to block on these passes being migrated. So I'm not sure this method of determining progress towards switching to NPM actually makes sense.

Somewhat along those lines, can you explain a bit how MachineFunction
passes and other passes can live within the same pass manager? The
split between "optimization" and "code generation" is a bit arbitrary,
and there are benefits to be had from running everything in the same
pass manager, because analyses can be preserved. With GlobalISel, it
may even be possible to carry analyses like dominator tree and loop
info from the IR world over to the MIR world.

Cheers,
Nicolai

-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
More information about the llvm-dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4