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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
