It is surprising that readnone implies writeonly

IR & Optimizations
1

It is really surprising to me that ‘readnone’ implies ‘writeonly’ and ‘readonly’.

Literally, ‘readnone’ means it wouldn’t access the memory and ‘writeonly’ means it may write to the memory. So there is a conflict naturally. How could a readnone things may write to the memory?

I could understand the original author may translate ‘writeonly’ as ‘wouldn’t read’. So ‘readnone’ could imply it wouldn’t read. It makes sense in the way.

It is the same for ‘readonly’. I feel like it is better to rename these attributes to:
readnone → nomemacess (NoMemAccess)
readonly → nomemwrite (NoMemWrite)
writeonly → nomemread (NoMemRead)

Now it looks natural that nomemacess implies nomemwrite and nomemread. Is there any one who has same feeling?

Thanks,
Chuanqi

2

Where is that implication written or implied?

I would prefer to have just 2 attributes: noread & nowrite, like Alive2, but now it’s hard to change things.
Plus historically, readnone had semantics other than just memory access. This has been cleaned up now (or is underway).

3

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.

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

4

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(...) { ... }

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

5

We could find this in llvm-project/InstrTypes.h at 2ae52326dab0a771b6167bc61a858389ac609ccc · llvm/llvm-project · GitHub and llvm-project/InstrTypes.h at 2ae52326dab0a771b6167bc61a858389ac609ccc · llvm/llvm-project · GitHub

Oh, it is hard to talk about confusing feelings. Everyone has different feelings. Since all the replies don’t feel it is bad, I’m OK with it.

6

I agree that the methods’ names are not ideal, even if the comments indicate the real semantics. The fact the comments are needed is a bad sign.
Attributes have grown organically and independently. Of course the result is not optimal, but changing the status quo is pretty hard. People haven’t met face to face in a long time, so progress is slow to inexistent in sensitive/complex areas.