[all-commits] [llvm/llvm-project] 8daaa2: [Support] Support nested parallel TaskGroup via wo...

[Fangrui Song via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8daaa26efdda3802f73367d844b267bda3f84cbe
      https://github.com/llvm/llvm-project/commit/8daaa26efdda3802f73367d844b267bda3f84cbe
  Author: Fangrui Song <i at maskray.me>
  Date:   2026-04-01 (Wed, 01 Apr 2026)

  Changed paths:
    M lld/test/ELF/merge-piece-oob.s
    M llvm/include/llvm/Support/Parallel.h
    M llvm/lib/Support/Parallel.cpp
    M llvm/unittests/Support/ParallelTest.cpp

  Log Message:
  -----------
  [Support] Support nested parallel TaskGroup via work-stealing (#189293)

Nested TaskGroups run serially to prevent deadlock, as documented by
https://reviews.llvm.org/D61115 and refined by
https://reviews.llvm.org/D148984 to use threadIndex.

Enable nested parallelism by having worker threads actively execute
tasks from the work queue while waiting (work-stealing), instead of
just blocking. Root-level TaskGroups (main thread) keep the efficient
blocking Latch::sync(), so there is no overhead for the common
non-nested case.

In lld, https://reviews.llvm.org/D131247 worked around the limitation
by passing a single root TaskGroup into OutputSection::writeTo and
spawning 4MB-chunked tasks into it. However, SyntheticSection::writeTo
calls with internal parallelism (e.g. GdbIndexSection,
MergeNoTailSection) still ran serially on worker threads. With this
change, their internal parallelFor/parallelForEach calls parallelize
automatically via helpSync work-stealing.

The increased parallelism can reorder error messages from parallel
phases (e.g. relocation processing during section writes), so one lld
test is updated to use --threads=1 for deterministic output.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications