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

[Neil Henning via llvm-dev]

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>