Skip to content

fix(ci): parallelize the clang-cl Windows lane with /MP - #67

Open
luthermonson wants to merge 1 commit into
mainfrom
fix/clang-windows-mp-parallel
Open

luthermonson wants to merge 1 commit into
mainfrom
fix/clang-windows-mp-parallel

Conversation

@luthermonson

Copy link
Copy Markdown
Contributor

Problem

build-windows-clang ("Windows (x86_64, clang-cl TAILCALL, experimental)") times out. A real run attached its runner fine, got through every setup step, and was cancelled at exactly ~2h during Build php8embed (clang-cl toolset) — the PHP compile itself. The MSVC lane (build-windows) fits under 2h and publishes its assets; only the clang-cl lane overruns.

Root cause

PHP's win32 build enables multi-process compilation (/MP) only inside if (VS_TOOLSET) in win32/build/config.w32:

if (VS_TOOLSET) {
    ARG_WITH('mp', ...'auto');
    ...
    ADD_FLAG('CFLAGS', ' /MP ');   // multi-process
}

This lane patches PHP_TOOLSET = "clang", so VS_TOOLSET is false and that entire block is skipped. PHP's batched inference rule (confutils.js, the non-PHP_MP_DISABLED branch) still hands many .c files to a single clang-cl invocation, but with no /MP that invocation compiles them single-process. clang-cl is slower per TU than MSVC, so the serial batch overruns the 2h ephemerd VM job_timeout. The MSVC lane fits precisely because it gets PHP's default /MP auto for free.

Fix

Extend the existing "Clone and patch php-src" step to add /MP to CFLAGS for the non-VS toolset, right after toolset_setup_common_cflags() (where CFLAGS is defined and VS_TOOLSET is already set):

if (!VS_TOOLSET && PHP_DEBUG != "yes") {
    ADD_FLAG("CFLAGS", " /MP ");
    STDOUT.WriteLine("Enabling multi process build (clang-cl, php-sdk lane)");
}
  • clang-cl honors /MP (this lane pins LLVM 22.x; /MP support landed long before).
  • Mirrors the VS lane's /MP auto (all cores) and keeps PHP's own debug-build carve-out.
  • Hard-fails if the toolset_setup_common_cflags(); anchor drifts, matching the other two patches in that step.
  • /MP reaches the compile because spc's --no-strip embed path reads CFLAGS= from the generated Makefile and re-passes it to nmake; PHP's configure writes the ADD_FLAG result into that line.

Only comments and the patch step change. No behavior change to the MSVC lane.

Validation

Dispatched a test build from this branch with release_tag_suffix=-clangpar so it uploads to v8.5.7-clangpar and cannot touch production v8.5.7 assets. Not merging until that run confirms the compile fits under 119 min.

The build-windows-clang job was cancelled at ~2h during "Build php8embed
(clang-cl toolset)" — the PHP compile itself.

Root cause: PHP's win32 build (config.w32) only enables multi-process
compilation (/MP) inside `if (VS_TOOLSET)`. This lane patches
PHP_TOOLSET="clang", so VS_TOOLSET is false and the /MP block is skipped.
PHP's batched inference rule still hands many .c files to one clang-cl
invocation, but without /MP that invocation compiles them single-process.
clang-cl is slower per TU than MSVC, so the serial batch overran the 2h
ephemerd VM job_timeout. The MSVC lane fits precisely because it gets
PHP's default `/MP auto` for free.

Fix: extend the existing config.w32 patch step to add `/MP` to CFLAGS for
the non-VS toolset (clang-cl honors /MP; this lane pins LLVM 22.x),
mirroring the VS behaviour and keeping PHP's own debug-build carve-out.
Hard-fails if the anchor drifts, like the other patches in that step.
@ephpm

ephpm Bot commented Sep 20, 2026

Copy link
Copy Markdown

ePHPm Preview — deployed (health check pending)

URL https://ephpm-php-sdk-pr-67.preview.ephpm.dev
Framework PHP
PHP 8.5
Deployed in 64.4s

Preview updates automatically on each push to this PR.

@ephpm
ephpm Bot temporarily deployed to preview-pr-67 September 20, 2026 04:20 Inactive
@ephpm
ephpm Bot temporarily deployed to preview-pr-67 September 20, 2026 04:20 Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant