llvm dev - May 2021 - How to use a custom InlineAdvisor with the new pass manager

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.

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.

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

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>