LLVM 21 readonly optimization breaks FFI writes through tag pointers

[SeanTAllen]

The LLVM 21 upgrade introduced a bug where FFI functions that write through pointer parameters have their writes optimized away in release builds.

The root cause: genfun_param_attrs maps Pony's tag capability to LLVM's readonly parameter attribute. This tells LLVM the function won't write through the pointer. That's incorrect when the pointer gets passed to an FFI function that does write through it (e.g., getsockname filling in a sockaddr).

This worked before LLVM 21 because older LLVM versions weren't as aggressive about exploiting readonly to eliminate loads. With LLVM 21, after inlining a Pony wrapper around an FFI call, the optimizer sees: memset to zero → call with readonly pointer → load, and concludes the load must return zero.

The symptom: lori's ListenerLocalAddress test fails in release mode because local_address() always returns port 0. It passes with --debug because the optimizer doesn't run.

A temporary fix that moves TK_TAG from the readonly group to the no-attribute group (with trn and ref) is up in #4926. val and box have real immutability/read-only guarantees that make readonly correct. tag only means identity-comparison-only in Pony, which doesn't imply the pointed-to memory won't be written through other paths.

This needs discussion about whether the temporary fix is the right long-term approach, or whether we need something more nuanced.

[SeanTAllen]

I'm going to merge the PR so we have a fix in place and we can discuss at sync if we want a different fix.

[SeanTAllen]

The tag-only fix in #4926 wasn't sufficient. Testing confirmed that val and box have the same problem — any Pony function that passes a val or box pointer to an FFI call that writes through it gets the writes optimized away. The capability on an FFI parameter is a Pony-side fiction for ergonomics; the C code doesn't honor it.

#4927 disables readonly on all capabilities as a temporary fix. A more targeted long-term fix would detect FFI calls in the function body and only skip readonly for parameters that flow to them.

[SeanTAllen]

Explored an alternative: restore readonly and mark Pony functions containing FFI calls as noinline. This prevents the inliner from propagating readonly into callers. It works for the direct case (caller → FFI wrapper), but fails at 3+ levels deep. If function A (readonly on param, no FFI) calls function B (readonly on param, has FFI, noinline), inlining A into its caller still exposes A's readonly promise. LLVM deduces B can't write through the pointer based on A's attribute alone, without needing to see inside B.

The only general fix would require whole-program analysis to trace parameters through the call graph to FFI calls. The blanket removal of readonly from #4927 remains the right approach.

[SeanTAllen]

The alternatives I did were all incorrect at some level.