[PATCH] D135962: [AA] Rename FunctionModRefBehavior (NFC)

[Nikita Popov via Phabricator via llvm-commits]

nikic created this revision.
nikic added reviewers: jdoerfert, nhaehnle, fhahn, reames, asbirlea.
Herald added a project: All.
nikic requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

As part of https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579, the `FunctionModRefBehavior` class sees a good bit of additional use, and I've found the name to be something of a mouthful. I'd like to rename it to something more concise. I have two suggestions:

- `FunctionModRefBehavior` -> `ModRefBehavior`. I don't think the `Function` prefix is adding anything here, and I think we will actually want to use this class to model memory effects of non-call instructions as well. While most non-call instructions are argmemonly ("arg" in the sense of "instruction operand" here), this is not true for volatile operations and other special instructions like fences, and having central modelling for this would prevent mistakes like D135863 <https://reviews.llvm.org/D135863>.
- `FunctionModRefBehavior` -> `MemoryEffects` (what this patch currently does). This would be in line with the terminology of the aforementioned RFC. I think this term is more obvious to people who are not familiar with our AA lingo.

Happy to bikeshed other variants though :)

This patch currently just updates the class definition. If we do the rename, I would of course also update other references. For the second option, I'd also rename `getModRefBehavior()` methods to `getMemoryEffects()`.


https://reviews.llvm.org/D135962

Files:
  llvm/include/llvm/IR/ModRef.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D135962.467779.patch
Type: text/x-patch
Size: 7895 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221014/6de281b4/attachment-0001.bin>