Page MenuHomePhabricator

[Attributor] Derive `willreturn` based on `mustprogress`
Needs ReviewPublic

Authored by jdoerfert on Tue, Jan 5, 3:09 PM.



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.

Diff Detail

Event Timeline

jdoerfert created this revision.Tue, Jan 5, 3:09 PM
jdoerfert requested review of this revision.Tue, Jan 5, 3:09 PM
Herald added a reviewer: baziotis. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: bbn. · View Herald Transcript
jdoerfert added inline comments.Wed, Jan 6, 6:58 AM

I think I can even remove this condition.

fhahn added inline comments.Mon, Jan 11, 7:20 AM

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.

jdoerfert added inline comments.Mon, Jan 11, 7:26 AM

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.
Here is the lang ref:

This function attribute indicates that a call of this function will either exhibit undefined behavior or comes back and continues execution at a point in the existing call stack that includes the current invocation. Annotated functions may still raise an exception, i.a., nounwind is not implied. If an invocation of an annotated function does not return control back to a point in the call stack, the behavior is undefined.

fhahn added a comment.Tue, Jan 12, 8:40 AM

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


Ah right, that makes sense. Not sure, but IMO the current wording could be a bit improved, but I am not really sure how.


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.