[PATCH] D60757: Fix a crash bug caused by a nested call of parallelForEach.

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 16 11:24:26 PDT 2019


sbc100 added a comment.

In D60757#1468973 <https://reviews.llvm.org/D60757#1468973>, @sbc100 wrote:

> So IIUC, this moves the parallelism to per-input-file, rather per-chuck-per-input-file.
>
> @ruiu presumably we want to restore more parallelism if we land this change?   Having said that perhaps this won't be much of regression for reasonable sized projects since the projects that benefit from high parallelism will most likely have many input files.   One concern is LTO, where there can be essentially one giant object file, in which case I think we would loose all our parallelism.  However I imagine in that case that the link time would massively dominated by the compile time?
>
> Otherwise LGTM.
>
> Also, it makes me sad that parallelForEach can't detect this behaviour,  especially since it leads to bugs that are hard to reliably reproduce.  Should we try to get parallelForEach fixed?


Sorry, I just saw https://reviews.llvm.org/D60758.  lgtm


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60757/new/

https://reviews.llvm.org/D60757





More information about the llvm-commits mailing list