This is an archive of the discontinued LLVM Phabricator instance.

[funcattrs] Fix incorrect readnone/readonly inference on captured arguments
ClosedPublic

Authored by reames on Dec 17 2021, 11:46 AM.

Details

Summary

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.

Diff Detail

Event Timeline

reames created this revision.Dec 17 2021, 11:46 AM
reames requested review of this revision.Dec 17 2021, 11:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 17 2021, 11:46 AM
reames added inline comments.Dec 17 2021, 11:48 AM
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
999

Note: This bit is arguably not part of the bug fix, but it's unreachable without it, and without it the bugfix causes massive test diffs.

Drive-by, I'm on vacation.

Glad someone fixes this, even if I was hoping we replace all this by invoking the Attributor only for the IR attributes we are looking for here.

llvm/lib/Transforms/IPO/FunctionAttrs.cpp
702

I don't know if it is checked but unwinding is the same issue as writes. The Attributor code might have even more corner cases covered.

reames added inline comments.Dec 17 2021, 12:48 PM
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
702

I don't believe we can have a well defined readonly throwing function.

This revision is now accepted and ready to land.Dec 21 2021, 2:26 AM
This revision was landed with ongoing or failed builds.Dec 21 2021, 9:34 AM
This revision was automatically updated to reflect the committed changes.