LLVM IR: redefinition of @perry_ic_0 in multi-module dylib compilation

[proggeramlug]

Summary

Perry v0.5.75 emits duplicate @perry_ic_0 global definitions within the same LLVM IR module, causing clang -c to reject the IR with error: redefinition of global '@perry_ic_0'.

Affects 11 out of 28 modules when compiling @perry/postgres as a dylib.

Repro

cd /path/to/deployment   # has package.json with compilePackages: ["@perry/postgres"]
perry compile --output-type dylib -o out.so handlers/main.ts

Output:

Error compiling module 'connection.ts' with --backend llvm: clang -c failed:
  error: redefinition of global '@perry_ic_0'
  @perry_ic_0 = private global [2 x i64] zeroinitializer
⚠ 11 module(s) failed to compile — linking with empty stubs

Environment

• Perry v0.5.75 (commit 70b9f31)
• Reproduces on both macOS (Apple Silicon, clang 17) and Linux x86_64 (clang 18)
• @perry/postgres v0.2.0 (28 modules total, 11 fail)

Analysis

The inline cache globals @perry_ic_0, @perry_ic_1, etc. appear to be emitted with module-local numbering that resets to 0 within each LLVM IR file. When a single .ts module uses multiple inline caches (e.g., multiple property accesses on different shapes), the counter resets and produces duplicates.

Likely introduced by the shape-transition cache perf work (v0.5.72 82bd7cc or v0.5.66–v0.5.67 range).

Note

Also: -mcpu=native in linker.rs:67 is ARM-only. On x86_64, clang rejects it — needs -march=native instead. Worked around with PERRY_LLVM_CLANG wrapper for now.

[proggeramlug]

Fixed by 8d50595 (the v0.5.76 Windows x86_64 support commit, fix #2 in the batch): ic_site_counter was being reset to 0 for every compiled function. Moved to a module-scoped LlModule.ic_counter threaded through every compile_function / compile_closure / compile_method / compile_module_entry / compile_static_method site.

Verified on a 3-module repro (lib_a/lib_b/main) with 7 property-access sites per module: each .ll file now emits unique @perry_ic_0..6 and clang accepts all three. Compile produced a working executable; --output-type dylib also succeeds.