[clang] [Clang][Driver] Final phase also determined by input (PR #218802)

[Nico Weber via cfe-commits]

https://github.com/nico commented:

This makes getFinalPhase linear in the number of inputs. You're adding a call to the version of getCompilationPhases from the body of a `for (auto &I : Inputs)` loop (marked "here" below), which means this makes the driver quadratic in the number of inputs. Here's a repro:

```
S=$(mktemp -d); mkdir -p $S/objs
for n in 2500 5000 10000 20000; do rm -f $S/rsp$n; for i in $(seq $n); do f=$S/objs/o$i.o; [ -e $f ] || : > $f; echo $f >> $S/rsp$n; done; done
hyperfine -N -w 2 -r 10 "bin/clang -### @$S/rsp2500 -o $S/out" "bin/clang -### @$S/rsp5000 -o $S/out" "bin/clang -### @$S/rsp10000 -o $S/out" "bin/clang -### @$S/rsp20000 -o $S/out"
```

With this:

54.0 ms, 132.4 ms, 395.1 ms, 1.386 s

With it reverted:

38.6 ms, 58.4 ms, 102.7 ms, 189.6 ms (0.2s overhead is also not great! but it's much less than with this patch.)

(23k inputs is realistic in chromium builds; this here adds over 2 seconds of overhead to our links.)

The fix is probably just to call `const phases::ID FinalPhase = getFinalPhase(Args, Inputs);` before that for loop in Driver::BuildActions and and then call the two-arg getCompilationPhases overload in that `for (auto &I : Inputs)` loop. Please audit the rest of the PR for similar quadratic slowdowns, and please fix that slowdown (or revert this PR).

Thanks!

(Also, see another comment below.)

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