[PATCH] D49041: [LangRef] Clarify undefined behavior for function attributes.

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jul 8 08:05:49 PDT 2018


nlopes added inline comments.


================
Comment at: docs/LangRef.rst:1540
+    If a readnone function reads or writes memory visible to the program, or
+    has other side-effects, the behavior is undefined. If a function reads from
+    or writes to a readnone pointer argument, the behavior is undefined.
----------------
uhm, in the way it's written, functions marked with readnone, readonly, writeonly, argmemonly cannot e.g. divide by 0. So either all divisions are guarded to ensure that they never trigger UB, or functions with potentially unsafe divisions cannot be marked as *only.
Is this intended?

For readnone/readonly I can see the motivation: this allows hoisting these functions safely (modulo the non-returning functions problem).
For write-only and argmemonly, what's the motivation to block any other UB?

Should the has-no-UB bit be split into a separate flag? Are there use cases for the clients of readnone/readonly? I guess at least ModRef could benefit of a readonly without the no-UB bit?


Repository:
  rL LLVM

https://reviews.llvm.org/D49041





More information about the llvm-commits mailing list