Since D86233 we have mustprogress which, in combination with
readonly, implies willreturn. The idea is that every side-effect
has to be modeled as a "write". Consequently, readonly means there
is no side-effect, and mustprogress guarantees that we cannot "loop"
forever without side-effect.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
2352 | I think I can even remove this condition. |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
2350 | Do we have to also ensure that the function is nounwind? In case of an exception, we would return to the closest exception handler and not return to a point in the existing call stack. |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
2350 | No, they are by design orthogonal. Willreturn "allows" to "come back through unwind. Basically, you will go back and unwind through the call of the function, that means you "return" to the call. So willreturn does not imply nounwind and willreturn does not guarantee there is no exception either.
|
The logic in general seems fine to me, but I'm not too familiar with the attributor internals, so it would be good for someone more familiar to take a look.
BTW, I put up a similar patch for -function-attrs D94502
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
2350 | Ah right, that makes sense. Not sure, but IMO the current wording could be a bit improved, but I am not really sure how. | |
2352 | I assume the MemAA.*ReadOnly helpers also return true if the function does not access memory? Then it would probably be simpler to just drop the check. |
LGTM thanks! It would probably be good to wait a bit with committing in case someone else more familiar with the attributor internals wants to chime in.
Do we have to also ensure that the function is nounwind? In case of an exception, we would return to the closest exception handler and not return to a point in the existing call stack.