Mircea Trofin via llvm-dev
2021-May-19 15:21 UTC
[llvm-dev] How to use a custom InlineAdvisor with the new pass manager
On Wed, May 19, 2021 at 5:27 AM Neil Henning via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hey list, > > I'm currently porting our HPC# Burst compiler over from the legacy pass > manager to the new pass manager. While nearly everything went fine, I've > hit one major hiccup that I can't seem to workaround - how can we have a > custom `InlineAdvisor` for Burst without modifying tip LLVM. >I'm trying to understand this better - you mean you'd want to load the InlineAdvisor from a dynamic library, or something like that?> > At present I've managed to completely bodge this locally by getting access > to the `OwnedAdvisor` member of `InlinerPass` through very UB means (make a > class of the same layout, casteroo, assign the field). Now this works in > that I don't have codegen regressions anymore, but obviously this isn't the > solution I want to ship! > > I was wondering if the list would object to us either: > > 1. Making the `OwnedAdvisor` field of `InlinerPass` protected, so I > could derive from `InlinerPass` and set the advisor. > 2. I could make the `getAdvisor` virtual, and assign it that way. > 3. Probably the 'best' fix would be to make `InlineAdvisorAnalysis` > somehow able to take a user-provided `InlineAdvisor` - although I'd rather > not use the static option `UseInlineAdvisor` to set this. I don't really > know how this solution would look if I'm honest. > > I'm trying to understand what amount of changes to tip of tree are OK foryour scenario. Option 1 means modifying a .h; maybe option 2 needs a recompile though (because virtual). So would option 3 (at this point, we can talk about purpose-building support for your scenario, basically - if rebuilding the compiler binaries is on the table) Thoughts from anyone? This is a blocker for us in the LLVM 13 timeframe> when we hope to enable the new pass manager as the default. > > Cheers, > -Neil. > > -- > Neil Henning > Senior Software Engineer Compiler > unity.com > _______________________________________________ > 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/20210519/28fd05b3/attachment.html>
Neil Henning via llvm-dev
2021-May-20 07:04 UTC
[llvm-dev] How to use a custom InlineAdvisor with the new pass manager
So what I need is for the default LLVM inliner to be able to use my InlineAdvisor in some fashion - without modifying tip LLVM *locally *to do so. So what I think I will have to do is land one of the proposals I stated originally (or a better idea from any of you fine folk) into LLVM *before *the LLVM 13 cutoff, so that when we pick up the LLVM 13 release in future we'll have the APIs available to set our own InlinerAdvisor. So to be clear - I'm totally ok to do a patch to LLVM to fix this, I just can't patch LLVM myself *locally *post-release because we are provided with a pre-built LLVM for some platforms we support. Hopefully that makes it a bit clearer? On Wed, May 19, 2021 at 4:21 PM Mircea Trofin <mtrofin at google.com> wrote:> > On Wed, May 19, 2021 at 5:27 AM Neil Henning via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hey list, >> >> I'm currently porting our HPC# Burst compiler over from the legacy pass >> manager to the new pass manager. While nearly everything went fine, I've >> hit one major hiccup that I can't seem to workaround - how can we have a >> custom `InlineAdvisor` for Burst without modifying tip LLVM. >> > > I'm trying to understand this better - you mean you'd want to load the > InlineAdvisor from a dynamic library, or something like that? > > >> >> At present I've managed to completely bodge this locally by getting >> access to the `OwnedAdvisor` member of `InlinerPass` through very UB means >> (make a class of the same layout, casteroo, assign the field). Now this >> works in that I don't have codegen regressions anymore, but obviously this >> isn't the solution I want to ship! >> >> I was wondering if the list would object to us either: >> >> 1. Making the `OwnedAdvisor` field of `InlinerPass` protected, so I >> could derive from `InlinerPass` and set the advisor. >> 2. I could make the `getAdvisor` virtual, and assign it that way. >> 3. Probably the 'best' fix would be to make `InlineAdvisorAnalysis` >> somehow able to take a user-provided `InlineAdvisor` - although I'd rather >> not use the static option `UseInlineAdvisor` to set this. I don't really >> know how this solution would look if I'm honest. >> >> I'm trying to understand what amount of changes to tip of tree are OK for > your scenario. Option 1 means modifying a .h; maybe option 2 needs a > recompile though (because virtual). So would option 3 (at this point, we > can talk about purpose-building support for your scenario, basically - if > rebuilding the compiler binaries is on the table) > > Thoughts from anyone? This is a blocker for us in the LLVM 13 timeframe >> when we hope to enable the new pass manager as the default. >> >> Cheers, >> -Neil. >> >> -- >> Neil Henning >> Senior Software Engineer Compiler >> unity.com >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-- Neil Henning Senior Software Engineer Compiler unity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210520/f1b2cf62/attachment.html>