[llvm-dev] Using the new pass manager for CodeGen

[via llvm-dev]

To facilitate further discussion I have posted a first attempt to get things moving in this direction:
https://reviews.llvm.org/D63890

To try this patch, one needs to run llc up to machine-cp, then run llc <file> --run-pass=none --run-new-pass=machine-cp ...

This patch is only an attempt to get things working; the changes made in llc are hacked up and just done to expose running the new pass manager. Moreso I am looking for feedback about the general approach for fitting the CodeGen passes into the new pass manager.

Charles

________________________________
From: Markus Lavin [markus.lavin at ericsson.com]
Sent: Wednesday, June 19, 2019 4:07 AM
To: Zhang, Charles; llvm-dev at lists.llvm.org; Fedor Sergeev
Cc: Magee, Joshua
Subject: Re: [llvm-dev] Using the new pass manager for CodeGen

> I would love to see Opt and CodeGen using the same pass manager (as my downstream project has already switched to NewPM in Opt).

FWIW I too would love to see CodeGen use the new PM.

Some months ago I worked on a patch, albeit mostly useful downstream, having BasicAA depend on LazyValueInfo but had to ultimately give up on it. With the old PM used in CodeGen I had lots of problems getting the dependencies right, debugging was difficult and nobody could really provide answers on exactly how it was supposed to work.

So that said even if there are no performance gains there would definitely be other benefits.

-Markus

________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Fedor Sergeev via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Wednesday, June 19, 2019 12:38 PM
To: Charles.Zhang at sony.com; llvm-dev at lists.llvm.org
Cc: joshua.magee at sony.com
Subject: Re: [llvm-dev] Using the new pass manager for CodeGen

Hi, Charles,

On 6/13/19 11:48 PM, via llvm-dev wrote:
Hi,

I am looking into potentially porting CodeGen and some of the passes to using the new pass manager. Two questions:

1. Has anybody made an attempt in this direction already? Maybe I am missing a branch out there that has started on this already. From what I can tell, there is no work in-tree in CodeGen that is aware of the new pass manager besides some assembly utilities in BackendUtils.cpp.
You are right, there is no activity in-tree in that direction to the best of my knowledge.
And every time I was asking on LLVM devmtg if anybody working on that the answer was - "nay".
My initial thoughts in this direction were that there would need to be some new pass manager machinery, for example, things like FunctionToMachineFunctionPassAdaptor that handles what MachineFunctionPass::runOnFunction used to do, along with the associated AnalysisManager plumbing to understand units of MIR.
Generally, what you describe is indeed a proper first step towards getting CodeGen on New-PM rails:
 - introduce IRUnits for Machine IR
 - provide generic handling for those new units everywhere in New-PM framework

The next step would be to start moving at least one backend towards it, and thats where the initiative kinda stalls.
I believe people working on CodeGen just do not find enough incentive to start that work.


2. Are there any compile time improvements expected from porting CodeGen passes in the first place? As far as I can tell, the llc pass pipeline seems to be fairly well fixed in terms of phase ordering, and all the analyses are thrown out from opt anyway.
I would expect real savings just by reusing non-Machine-IR analyses.
As soon as you use the same llvm state/module/etc for both Opt and CodeGen purposes
(thats what I believe many do, at least our JIT compiler does that). That will allow you
to reuse analysis manager and thus keep every cached analysis there.

I would love to see Opt and CodeGen using the same pass manager (as my downstream project has already switched to NewPM in Opt).

Said that, perhaps analyses are not a current performance bottleneck in CodeGen (I bet instruction selection will always trump anything else).
So this is more about overall consistency of operations rather than crazy performance gains.

regards,
  Fedor.

Thanks,
Charles



_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/c28303b6/attachment.html>