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>
David Blaikie via llvm-dev
2019-Jun-14 05:09 UTC
[llvm-dev] Using the new pass manager for CodeGen
[+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>
Fedor Sergeev via llvm-dev
2019-Jun-19 10:38 UTC
[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 > 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>
Markus Lavin via llvm-dev
2019-Jun-19 11:07 UTC
[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/20190619/530fb986/attachment.html>