[PATCH] D115961: [funcattrs] Fix incorrect readnone/readonly inference on captured arguments

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: jdoerfert, sstefan1, nikic, aeubanks, modimo.
Herald added subscribers: ormris, bollu, hiraditya, mcrosier.
reames requested review of this revision.
Herald added a project: LLVM.

This fixes a bug where we would infer readnone/readonly for a function which passed a value to a function which could capture it.  With the value captured in memory, the function could reload the value from memory after the call, and write to it.  Inferring the argument as readnone or readonly is unsound.

@jdoerfert apparently noticed this about two years ago, and tests were checked in with 76467c4, but the issue appears to have never gotten fixed.

Since this seems like this issue should break everything, let me explain why the case is actually fairly narrow.  The main inference loop over the argument SCCs only analyzes nocapture arguments.  As such, we can only hit this when construction the partial SCCs.  Due to that restriction, we can only hit this when we have either a) a function declaration with a manually annotated argument, or b) an immediately self recursive call.

It's also worth highlighting that we do have cases we can infer readonly/readnone on a capturing argument validly.  The easiest example is a function which simply returns its argument without ever accessing it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115961

Files:
  llvm/lib/Transforms/IPO/FunctionAttrs.cpp
  llvm/test/Transforms/FunctionAttrs/readattrs.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D115961.395180.patch
Type: text/x-patch
Size: 5176 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211217/6dfb307d/attachment.bin>