llvm dev - Jun 2019 - Using the new pass manager for CodeGen

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. 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.

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.

Thanks,
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190613/732639a3/attachment.html>

[+Chandler, Master of Passes (dude who wrote the new pass manager and might
have some context on any ongoing work)]

On Thu, Jun 13, 2019 at 9:09 PM via llvm-dev <llvm-dev at lists.llvm.org>
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. 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.
>
> 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.
>
> Thanks,
> Charles
> _______________________________________________
> LLVM Developers mailing list
> 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/20190613/77f9aad3/attachment-0001.html>

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
> 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/20190619/2c89ada3/attachment-0001.html>

> 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/20190619/530fb986/attachment.html>