[llvm] [TailDuplicator] Add a limit on the size of predecessors (PR #78582)

[Quentin Dian via llvm-commits]

DianQK wrote:

> the test should be an MIR test right? then it's less prone to various changes affecting the exact codegen of the IR

Yes, but that would make this test case poorly maintained? I'm not sure, but I can change this.

> do we actually know why the previous patch caused things to blow up in this pass? i.e. where the memory usage spike actually happened?

It looks like the default branch of switch creates an if statement (compare instruction)? This results in two successors.
The previous patch did one thing, replace the default branch with an unreachable instruction. Then `TailDuplicator` can duplicate blocks into predecessors.
Since we revert the previous patch, we can't reproduce it directly in the main branch. But it can be reproduced by replacing it with an unreachable default branch in the C source code. e.g.

```
    case 127:  out1 = b[2] >> 31; break; \
    default:  __builtin_unreachable(); break; \
```

> was it just that we were doing too much tail duplication after the other change produced code that tended to be tail duplicated?

I think so.
I checked the time consumption of lld with `-time-trace` (`llc -O1 oom.bc -time-trace -time-trace-file=trace.json -filetype=null`). It takes 4s to complete on my device. About 1.3s is `Early Tail Duplication`. And 1.3s is `Eliminate PHI nodes for register allocation`. (I tried `perf`, but maybe it's the environment of my machine that makes this unavailable.)
I had to use TimeProfiler. `tailDuplicateAndUpdate` and `tailDuplicateAndUpdate` occupy half the time, respectively.

 > or is there an underlying algorithmic problem that we can fix?

I'm not sure, but I can try if I need to. But I don't know much about MIR and performance improvements.
I'm also a little concerned about the code size, which seems to increase from about 50K to about 200K for the initial example. :3

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