We can sometimes propegate `nocapture` attributes from caller arguments to callsite arguments. This can occur if between the callsite the end of a returning basic block, there are no may-write instructions. This works because at any return statement in the caller, any pointer marked `nocapture` must not have been captured. Readonly instructions cannot change whether a pointer has been captured in memory or not, so we can also say that after the final may-write in a returning basic-block, any `nocapture` argument may not be captured in memory. ``` call void @foo(ptr %p) %r = or i32 %a, %b ret i32 %r ``` `@foo` is a candidate as after the `@foo` callsite returns, the state of any captured pointers cannot change before the caller returns. ``` call void @bar(ptr %p) %r = or i32 %a, %b store i32 %r, ptr %other ret void ``` `@bar` is not a candidate as after the `@bar` callsite returns, there are memory writes which may change the state of captured pointer before the caller returns. The other capture method, via return, is also ignorable here. If the callsite's return value contributes to the caller's return value, then the callsite's return value could not have captured any `nocapture` arguments, otherwise it would violate the caller's attribute. If the callsite's return value does not contribute to the caller's return value then the return value is dead-code, as there are no more may-write operations between the callsite and the caller's return, so there is no way for the callsite's return value to be visible.

We can sometimes propegate `nocapture` attributes from caller arguments to callsite arguments. This can occur in in the following cases: 1) The callsite is in a basic block that ends with a return statement. 2) Between the callsite the end of its basic block there are no may-write instructions. 3) The return value of the callsite is not used (directly or indirectly) as the address of a may-read instruction. 4) There are allocas or leaked (not freed or returned) mallocs reachable from the callsite. These requirements are intentionally over conservative. We are only trying to catch relatively trivial cases. Requirements 1 & 2 are there to ensure that after the callsite has returned, the state of any captured in memory pointers cannot change. This implies that if the caller has any nocapture in memory gurantees, that state has been reached by the end of the callsite. Requirements 3 & 4 are to cover cases where pointers could escape the callsite (but not the caller) through non-dead code. Any return value thats loaded from (or used to create a pointer that is loaded from) could have derived from an argument. Finally, allocas/leaked mallocs in general are difficult (so we avoid them entirely). Callsites can arbitrarily store pointers in allocas for use later without violating a nocapture gurantee by the caller, as the allocas are torn down at caller return. Likewise a leaked malloc would not be accessible outside of the caller, but could still be accessible after the callsite. There are a variety of complex cases involving allocas/leaked mallocs. For simplicity, if we see either we simply fail.

We can sometimes propegate `nocapture` attributes from caller arguments to callsite arguments. This can occur if between the callsite the end of a returning basic block, there are no may-write instructions. This works because at any return statement in the caller, any pointer marked `nocapture` must not have been captured. Readonly instructions cannot change whether a pointer has been captured in memory or not, so we can also say that after the final may-write in a returning basic-block, any `nocapture` argument may not be captured in memory.n in the following cases: ```1) The callsite is in a basic block that ends with a return statement. 2) Between the call void @foo(ptr %p)site the end of its basic block there are no %r = or i32 %a, %b ret i32 %r may-write instructions. ```3) The return value of the callsite is not used (directly or indirectly) `@foo` is a candidate as after the `@foo` callsite returns, the as the address of a may-read instruction. state of any captured pointers cannot change before the caller4) There are allocas or leaked (not freed or returned) mallocs reachable returns from the callsite. ```These requirements are intentionally over conservative. We are only trying call void @bar(ptr %p)to catch relatively trivial cases. Requirements 1 & 2 are there to ensure that after the callsite has %r = or i32 %a,returned, the state of any captured in memory pointers cannot change. %bThis stoimplies that if the caller has any nocapture i32 %rn memory gurantees, ptr %otherthat ret voidstate has been reached by the end of the callsite. Requirements 3 & 4 are to cover cases where pointers could escape the ```callsite (but not the caller) through non-dead code. Any return value thats `@bar` is not a candidloaded from (or used to create as af pointer the `@bar` callsite returns,at is loaded from) could have there are memory writes which may change the state of capturedderived from an argument. Finally, allocas/leaked mallocs in general are pointer before the caller returns. The other capture method, via return, is also ignorable heredifficult (so we avoid them entirely). If theCallsites can arbitrarily store callsite's return value contributes to the caller's return value, thenpointers in allocas for use later without violating a nocapture gurantee by the callsite's return value could not have captured any `nocapture`er, as the allocas are torn down at caller return. Likewise a arguments, otherwise itleaked malloc would violate the caller's attribute.not be accessible outside of the caller, If thebut could callsite's return value does not contribute to the caller's returnstill be accessible after the callsite. There are a variety of complex value then the return value is dead-codecases involving allocas/leaked mallocs. For simplicity, as there are no moreif we see either we may-write operations between the callsite and the caller's return, sosimply fail. there is no way for the callsite's return value to be visible.