[llvm] [KeyInstr] Fully support mixed key/non-key inlining modes (PR #144103)

[Orlando Cazalet-Hyams via llvm-commits]

OCHyams wrote:

ty 

> Is it not feasible to check the optimisation mode here, avoiding the performance hit to O0? While there may be frontend/LTO reasons why key-and-non-key instructions could be mixed, one of the major reasons why KIs is needed is due to instruction-schedulers shuffling instructions around, which doesn't happen at O0. We could reasonably say "Key instruction is off at O0 anyway, we're not honouring it if you managed to convince something to be inlined into an optnone function".
> 
> If that's not alright, IMO it's OK to once again let O0 pay the price -- it's increasing from a low base anyway. Plus, the MC-layer optimisations we're getting up shortly gives it a 1.2% speedup.

For posterity - chatting offline - this is referring to an MC layer patch that's already landed - [compile-time-tracker-link](https://llvm-compile-time-tracker.com/compare.php?from=705e27c23474f3177670a791b5b54eefedee0cd8&to=26d9cb17a6e655993c991b66b21d5c378256d79b&stat=instructions%3Au).

Checking the optimisation level could work, but if the costs are within the realm of acceptable I prefer to avoid the additional complexity and edge case (the edge case that exists before this patch only regresses to something close to existing behaviour, rather than something worse). So, I'd lean towards having O0 paying the price unless anyone feels very strongly that the cost isn't acceptable (and hopefully our improvements to -g performance are considered there).


https://github.com/llvm/llvm-project/pull/144103