[flang-commits] [flang] [flang] Propagate INTENT(IN) dummy arguments as readonly (PR #207732)

[Sergey Shcherbinin via flang-commits]

SergeyShch01 wrote:

> My only slight concern is related to the fact that we may actually write to intent(in) arguments in the context of copyouts. For valid programs, this write is a no-op (should be rewriting the same content), but I am curious if LLVM could optimize it in crazy way because it assumes the write is unreachable because of the readonly attribute. Do you know?


That is a very good concern. LLVM readonly is a semantic guarantee, not merely an optimization hint. The [LLVM Language Reference](https://llvm.org/docs/LangRef.html#parameter-attributes) states:
If a function writes to a readonly pointer argument, the behavior is undefined.

A store remains a write even when it stores the value already present in memory. The LangRef makes this explicit for read-only memory effects: writing is immediate undefined behavior, “including the case where the location is read from and then the same value is written back.”
This does not depend on whether the copy-out is inlined. Keeping the store inside an opaque runtime call may prevent LLVM from seeing the violation today, but it does not make the IR contract valid. LTO, IPO, or future runtime inlining could expose the store and allow LLVM to optimize under the assumption that it cannot occur. In particular, constant argument promotion may replace an argument with a constant global placed in read-only storage, in which case a hidden copy-out store could result in a fault.
To avoid relying on the current opacity of the runtime call, the latest commit restricts direct-data readonly propagation to by-reference, rank-zero, non-character intrinsic dummy arguments. Such arguments do not require array-section packing, contiguity temporaries, or compiler-generated array copy-out, so the scenario above cannot arise. Arrays, assumed-rank arguments, character arguments, and derived types are excluded for now.
Once copy-out lowering has a robust way to guarantee that no store is performed for read-only destinations—for example, by suppressing copy-back or using an appropriate change-detection scheme—we can safely extend the coverage to the remaining types. 



https://github.com/llvm/llvm-project/pull/207732