Re: [PATCH] Run the bootstrap object comparison in parallel
Jeffrey Law <[email protected]>
| Newsgroups | gmane.comp.gcc.patches |
|---|---|
| Message-ID | <[email protected]> |
On 8/4/2026 10:51 AM, Jeffrey Law wrote: > > > On 7/21/2026 9:28 AM, [email protected] wrote: >> From: Kyrylo Tkachov <[email protected]> >> >> The stage 2 and stage 3 object comparison runs one command per object >> in a >> serial shell loop. Everything after it waits while an otherwise idle >> machine >> compares thousands of objects. >> >> Generate one make target per object and run the comparisons through >> $(MAKE), >> so they share the original jobserver. Keep the generated makefile >> and result >> shards invocation-specific, clean them on normal and signal exits, >> and sort >> the shards before creating the traditional .bad_compare diagnostic. >> Files in >> the exclusion list still only warn. Comparator statuses other than >> zero or >> one now report an operational error instead of being treated as equal. >> >> The tail-based fallback for cmp implementations without byte skipping >> used >> fixed temporary names. Give those files process-specific names, >> clean them >> with a trap, and preserve the same status contract for tail failures and >> signals. >> >> On highly parallel AArch64 and x86_64 systems this reduces comparison >> wall >> time by about 95%. >> >> ChangeLog: >> >> * Makefile.tpl ([+compare-target+]): Run object comparisons >> through an >> invocation-specific parallel sub-make. Collect sorted failure >> shards >> and clean temporary state on exit. >> * Makefile.in: Regenerate. >> * configure: Regenerate. >> >> config/ChangeLog: >> >> * acx.m4 (ACX_PROG_CMP_IGNORE_INITIAL): Use process-specific >> temporary >> files and clean them on exit. Diagnose tail failures as errors. >> >> Signed-off-by: Kyrylo Tkachov <[email protected]> > Given the utility of the bootstrap comparison test, I hope you you > tested with a forced failure to ensure it'll trigger failures properly. > > Assuming you've done a force failure test, OK. BTW, I think this cut about 2hrs off the bootstrap time for hppa-linux-gnu on my 40c systems. Similarly for alpha. I suspect the others will show similarly sized gains (m68k, loongarch, sh4, etc). Essentially everything where I'm using QEMU user mode emulation to provide an emulated native environment suitable for bootstrapping and regression testing I would expect to see comparable gains. It's a full 10%+ improvement in the total cycle time. Jeff