[PATCH] D79636: [LangRef] Clarify the semantics of the `byval` attribute
Johannes Doerfert via Phabricator via cfe-commits
cfe-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 cfe-commits
mailing list