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

[Sergey Shcherbinin via flang-commits]

================
@@ -187,6 +187,30 @@ asImplicitArg(Fortran::evaluate::characteristics::DummyDataObject &&dummy) {
                                                        std::move(shape)));
 }
 
+/// An INTENT(IN) data object passed by reference is not modified by the callee,
+/// so the LLVM `readonly` argument attribute can be set. Notes on the
+/// exclusions:
+///   - VALUE, POINTER, and ALLOCATABLE dummies require ABI- or
+///     descriptor-specific handling before `readonly` can be applied and are
+///     left out of scope;
+///   - ASYNCHRONOUS memory may change underneath the callee;
+///   - VOLATILE+INTENT(IN) is prohibited by the standard (C870); kept here
+///     defensively.
+/// TARGET and derived types are intentionally allowed: any write that
+/// INTENT(IN) still permits (e.g. writing the target of a POINTER component)
+/// goes through a pointer loaded from the object, not through the argument
+/// pointer, and hence does not violate LLVM `readonly` (which only constrains
+/// the argument and pointers based on it).
+static bool dummyArgIsReadOnly(
+    const Fortran::evaluate::characteristics::DummyDataObject &obj) {
+  using Attrs = Fortran::evaluate::characteristics::DummyDataObject::Attr;
+  return obj.intent == Fortran::common::Intent::In &&
+         !obj.attrs.test(Attrs::Value) && !obj.attrs.test(Attrs::Pointer) &&
+         !obj.attrs.test(Attrs::Allocatable) &&
----------------
SergeyShch01 wrote:

Thanks for the clarification. The updated revision now handles both INTENT(IN) ALLOCATABLE and POINTER dummies using shallow readonly semantics. fir.read_only is attached to the descriptor reference and translated to LLVM readonly, so it protects the descriptor storage itself, but not the data addressed by the descriptor.
For POINTER, the target may therefore still be modified. For ALLOCATABLE, this does not yet express the stronger Fortran contract covering the allocated data. A richer MLIR representation distinguishing descriptor readonly from data readonly would be useful for call side-effect analysis, but I have left that as future work.

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