And revert much of D91567.
D91567 ended up putting the mandatory inlining pass in a different CGSCC
pipeline than the function simplification pipeline, causing alwaysinline
functions to not be optimized when inlined into another function,
causing PR48734. Much of the design of D91567 was to potentially support
future work to run the function simplification pipeline twice, once
before inlining. However, that hasn't happened yet and can be revisited
in the future.
This sorts the initial list of CallBases so that we handle alwaysinline
calls first. Since we want to process as many calls in one functions at
a time, we have to use a stable sort.
This actually doesn't handle all alwaysinline cases properly. For
example, within an SCC, if an alwaysinline function contains another
alwaysinline call and is inlined, the newly inlined alwaysinline call
will be processed after other calls since it was not in the initial list
of CallBases. Then we can end up with another case of PR46945 where an
alwaysinline function can't be inlined because a mutually recursive
function was inlined first. However, it seems rare enough to not bother
with this case.