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

[Mircea Trofin via llvm-dev]

Ah, I see. There's a precedent for using custom InlineAdvisors, see for
instance (in Inliner.cpp) how the ReplayInlineAdvisor is handled. I suppose
you could do the same?

On Thu, May 20, 2021 at 12:04 AM Neil Henning <neil.henning at unity3d.com>
wrote:

> 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/57168903/attachment.html>