[llvm] [Analysis] Visit orphan Functions in CGPassManager catch-up loop (PR #194219)

[Janek van Oirschot via llvm-commits]

JanekvO wrote:

> Crashes and miscompiles on targets based on scheduling a ModulePass after the CGSCC section or not do

Sorry, I'm not sure I completely understand the end of this sentence

> Enabling/disabling IPRA changes only register allocation strategy and not if orphan functions are emitted on certain platforms.

I know what you're suggestion with this sentence but as a nit: enabling IPRA does enforce CGSCC ordering which visibly changes emit ordering in asm

> No binary performance impact when optimization levels are enabled due to later stripping stages and no impact on debug code generation since it already generates everything.

I probably have missed it; but what are the stripping stages?

> I did it slightly different since I didn’t want to impact other passes

Forgive my ignorance but, what impact would this have? In my naive view, with the false-as-default, wouldn't that have no impact on any other uses of scc_iterator?

> I believe this can break at any point when CGSCCPass and another ModulePass is used in the backend.

Might've been a AMDGPU-ism at the time, I recall some DCE removing uncalled internal/private functions

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