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

[Fangrui Song via cfe-commits]

MaskRay wrote:

> 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 --ld-path=/usr/bin/true  @$S/rsp2500 -o $S/out" "bin/clang --ld-path=/usr/bin/true  @$S/rsp5000 -o $S/out" "bin/clang --ld-path=/usr/bin/true @$S/rsp10000 -o $S/out" "bin/clang --ld-path=/usr/bin/true @$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 bad than with this patch.)
> 
> (23k inputs is realistic in chromium builds; this here adds over 2 seconds of pure driver 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.)

@nico Reverting and refixing is fine with me.

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