It is surprising that readnone implies writeonly

[jdoerfert]

@fhahn

As @nlopes mentioned, the writeonly and readnone attributes do not only specify behavior with respect to memory, but any state visible outside the function.

They may or may not, or do sometimes, etc. Certainly not in a proper and consistent way. We should have proper attribution for all “effects” and if we want to model things as memory effects that are not strictly speaking memory effects we should create special “pseudo-memory” categories.

I don’t remember what the thread was but I think my last proposal would have looked somewhat like this:

Function Attributes: sideeffects(read:globals, write:arguments, sync, maynotreturn)
define void @foo(...) { ... }

@fhahn

I am not a native speaker but I don’t think there necessarily is a conflict. writeonly may or may not write to memory. In the readnone case, the may not part applies. Granted, the terminology may be a bit more complicated than necessary.

^ Agreed. Terminology is “grown” not “designed”. I don’t see a conflict/inconsistency in this particular part.