[PATCH] D79636: [LangRef] Clarify the semantics of the `byval` attribute

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat May 9 16:29:26 PDT 2020


jdoerfert marked an inline comment as done.
jdoerfert added inline comments.


================
Comment at: llvm/docs/LangRef.rst:1052-1053
+    memory of the callee. That means, a callee can write a ``byval`` parameter
+    and still be ``readonly`` or ``readnone`` because the write is, similar to
+    a write to an ``alloca``, not visible from the outside. To create the copy
+    the original memory, which is the call site argument, is always read. This
----------------
arsenm wrote:
> Should this also specify the meaning of readonly/readnone as a callee side parameter attribute? is it disallowed to write to a readonly byval argument?
> Should this also specify the meaning of readonly/readnone as a callee side parameter attribute?

I thought by specifying what memory the call site and argument pointer refer to, the readonly/readnone (and other attributes) fall in line. They apply to the respective memory.

> is it disallowed to write to a readonly byval argument?

Writing *any* `readonly` argument is UB, I mean the store instruction causes UB.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79636/new/

https://reviews.llvm.org/D79636





More information about the llvm-commits mailing list