[llvm-dev] How to use a custom InlineAdvisor with the new pass manager

[Mircea Trofin via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210519/28fd05b3/attachment.html>