Can someone explain it in a language that mere mortals understand?
[[carries_dependency]] is used to allow dependencies to be carried across function calls. This potentially allows the compiler to generate better code when used with std::memory_order_consume for transferring values between threads on platforms with weakly-ordered architectures such as IBM's POWER architecture.
In particular, if a value read with memory_order_consume is passed in to a function, then without [[carries_dependency]], then the compiler may have to issue a memory fence instruction to guarantee that the appropriate memory ordering semantics are upheld. If the parameter is annotated with [[carries_dependency]] then the compiler can assume that the function body will correctly carry the dependency, and this fence may no longer be necessary.
Similarly, if a function returns a value loaded with memory_order_consume, or derived from such a value, then without [[carries_dependency]] the compiler may be required to insert a fence instruction to guarantee that the appropriate memory ordering semantics are upheld. With the [[carries_dependency]] annotation, this fence may no longer be necessary, as the caller is now responsible for maintaining the dependency tree.
e.g.
void print(int * val)
{
std::cout<<*val<<std::endl;
}
void print2(int * [[carries_dependency]] val)
{
std::cout<<*val<<std::endl;
}
std::atomic<int*> p;
int* local=p.load(std::memory_order_consume);
if(local)
std::cout<<*local<<std::endl; // 1
if(local)
print(local); // 2
if(local)
print2(local); // 3
In line (1), the dependency is explicit, so the compiler knows that local is dereferenced, and that it must ensure that the dependency chain is preserved in order to avoid a fence on POWER.
In line (2), the definition of print is opaque (assuming it isn't inlined), so the compiler must issue a fence in order to ensure that reading *p in print returns the correct value.
On line (3), the compiler can assume that although print2 is also opaque then the dependency from the parameter to the dereferenced value is preserved in the instruction stream, and no fence is necessary on POWER. Obviously, the definition of print2 must actually preserve this dependency, so the attribute will also impact the generated code for print2.