If a function FA has an argument ARG with the `nocapture` attribute it implies that any function callsites FB from within FA also don't cause ARG argument to be captured. It's useful to set this explicitly, as if function FA get inlined, we don't want to lose the information that the specific callsites can't cause ARG to be captured.

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.

If a function FA has an argument ARG with thWe can sometimes propegate `nocapture` attribute its from caller implies that any function callsites FB from within FA also don't causearguments to callsite arguments. This can occur if between the callsite the end of a returning basic ARG argument to be captured.block, It's useful to set this explicitlythere are no may-write instructions. This works because at any return statement in the caller, as ifany pointer function FA get inlinedmarked `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, we don't want to lose the information thatso there is no way for the callsite's return value to be visible. the specific callsites can't cause ARG to be captured.