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:
- Making the
InlinerPassprotected, so I could derive from
InlinerPassand set the advisor.
- I could make the
getAdvisorvirtual, and assign it that way.
- Probably the ‘best’ fix would be to make
InlineAdvisorAnalysissomehow able to take a user-provided
InlineAdvisor- although I’d rather not use the static option
UseInlineAdvisorto 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.