[ASDAlexander77]

Summary

This is phase 2 of 32-bit support. 32-bit Windows programs (-mtriple=i686-pc-windows-msvc) now link and run under -mm=gc, -mm=rc and -mm=none. The plan is in docs/superpowers/plans/2026-09-21-32-bit-phase-2-native-libs.md. The spec's Phase 2 section has an "As built" table and the open issues.

• Lowering uses the target's data layout. LLVMTypeConverter is now built from the module's llvm.data_layout, not from LLVM's default layout. This is what makes i686 struct and union sizes and getIntPtrType correct. The number of i686 modules with ptrtoint ptr … to i64 goes from 288 to 0. A missing layout is now a hard error, and so is a malformed one; unit tests cover both. The wasm32 layout that was hardcoded here is gone; it was wrong (it lacked i128:128).
• Some triples are refused. For x86_64-pc-linux-gnux32, mips64 gnuabin32 and aarch64 ilp32, the pointer width of the architecture and of the ABI differ. MLIRGen and lowering would then disagree, so the compiler now refuses these triples and names the triple in the error.
• x86 Boehm. prepare_3rdParty.bat <cfg> x86 builds it. This is opt-in; with no second argument, nothing changes. It runs the new scripts\build_gc_<cfg>[_shared]_vs_x86.bat, which copy their output into 3rdParty\gc[dll]\x64\<cfg>\lib\x86\. The --gc-lib-path / --gc-shared-lib-path values already used for x64 therefore work for x86 without change. The x64 files stay byte-identical; only the x86\ subdirectory is added.
• x86 async runtime. tslang/runtime/CMakeLists.txt is a standalone project that builds TypeScriptAsyncRuntime for any arch, with no LLVM or MLIR link dependency. It uses the same sources as the in-tree library. I checked it against the in-tree library at x64 first: three async tests gave identical output with each. Build it with scripts\build_tslang_runtime_<cfg>_x86.bat, then pass --tslang-lib-path=__build\tslang-runtime\<cfg>.
• The compiler finds and checks x86 libraries.
  • For a Windows x86 target it looks in <lib path>\x86\.
  • If a library is missing there, the error names the script that builds it and the path to pass.
  • Dump::coffMachine reads the COFF machine of gc.lib, gc.dll and TypeScriptAsyncRuntime.lib. A library built for the wrong arch is an error before the link, and that applies in both directions: an x86 lib found by an x64 build is caught too.
  • Non-Windows targets and wasm are unchanged.

Behavior change on x64: fixes a miscompile

Lowering used to size types with LLVM's default layout, which aligns i64 at 4 bytes. That under-sized a union member such as {i1, i64} at 12 bytes; its real size is 16. So in {flag; a: s32; b: s32} | {flag; v: bigint} the bigint lost its high half: 9007199254740993 read back as 1. This happened on JIT and exe, at every opt level and under every memory model. The new corpus test 00bigint_struct_layout covers it.

Apart from that fix, the x64 IR is unchanged. The other targets were checked too, by compiling the whole corpus with the compiler from before and after this change:

• Linux x64 and wasm64: the only difference is 00bigint_struct_layout.
• wasm32: the datalayout line changes.
• On all three targets, no file that compiled before fails now.

The remaining differences are run-to-run noise. Some generated names contain hash IDs, and equal-size union members are ordered by hash. tslang/test/mask-ir.sh masks most of this, and lists the files it can't mask.

Not in this PR (open issues, recorded in the spec)

• Importing an x86 DLL fails at compile time with ./lib.dll: Can't open: Unknown error (0xC1). mlirGenImportSharedLib loads the DLL into the 64-bit compiler to read __decls. Building the x86 DLL itself works. The fix is to read __decls from the file instead, planned for phase 4.
• No x86 TypeScriptRuntime (the JIT DLL), because --emit=jit refuses x86 targets.
• Win32 x86 exceptions are phase 3. The default library, async and the full suite at 32-bit are phase 4. A likely cause of the i686 00for_await unrealized_conversion_cast: upstream ConvertAsyncToLLVMPass uses LLVM's default layout.
• Bugs found along the way, not fixed here. None is specific to 32-bit, and none is filed yet:
  • A union member's field that lies in the padding of the member used for storage reads back 0. This is x64 too and existed before this change. 00bigint_struct_layout documents it and does not assert that field.
  • bigint: printing a bigint, or using one in a template string, crashes. An optional bigint parameter fails materialization. Unions of tuple or object members can't be narrowed back to a member.
  • A let p: Node | null is not narrowed in a loop condition or body; for (…; p; …) produces an invalid op.
  • const arr: T[] = []; arr.push(…) is rejected.

Test plan

• Windows Release suite: ctest -j 16 -C Release passes 2766/2766. That is the old 2765 plus 00bigint_struct_layout.
• MLIRGenTests passes 144/144, including the new LoweringDataLayout tests.
• tslang/test/check-x86-run.sh passes 6/6: hello and gc_stress × gc/rc/none, each a PE with machine 0x14C, exiting 0 with exact output. Under gc, gc_stress ran 102 collections and freed 31.7 MB in a 628 KiB heap, and the list it keeps alive still sums correctly. The script runs release builds only; debug x86 builds were checked by hand.
• tslang/test/check-x86-libs.sh passes 11/11: a missing x86 directory, a wrong-arch lib or DLL in either direction, and correct x86 exe and DLL layouts.
• tslang/test/check-datalayout.sh passes 6/6, including the wasm32 i128:128 layout and the refusal of x86_64-pc-linux-gnux32.
• x64 IR diffed with tslang/test/compare-ir.sh against the pre-change compiler; results are above.
• Linux CI. Not run locally.

Only the ctest suite and MLIRGenTests run in CI. The four scripts (check-datalayout.sh, compare-ir.sh, check-x86-libs.sh and check-x86-run.sh) are run by hand. The two x86 scripts need the x86 libraries built first, and CI does not build them.

🤖 Generated with Claude Code