Confusions around nocapture and sret

In the language reference (https://llvm.org/docs/LangRef.html), in the
definition of nocapture, it says "This is not a valid attribute for
return values". However I have seen it often that nocapture comes
together with sret attribute:
https://github.com/llvm/llvm-project/search?q=noalias+nocapture+sret

A few questions:
1. Is the LangRef out-of-date for sret+nocapture?
2. Is an sret argument to a function guaranteed to be nocapture? (i.e.
a pointer cannot escape through a sret argument?)
3. What about sret+noalias? Is that guaranteed to be nocapture?

1) I don't think so. sret is an attribute for *arguments* that declares they were created from source language return values, it's not a return value attribute.

2) I believe sret shuould imply nocapture when the frontend generates it. So yes.

3) noalias has no direct implications towards nocapture.

~ Johannes

If sret implies nocapture, should we modify
CallBase::doesNotCapture(unsigned OpNo) to include this case?
Currently it only checks whether it has nocapture attribute.

I strongly suggest to emit nocapture with sret in the frontend
instead.

~ Johannes

I don't think that is actually feasible. For example, consider this C++ file:

#include <set>

struct Example;
std::set<Example*> live_examples;
struct Example {
	Example()
	{
		live_examples.insert(this);
	}
	~Example()
	{
		live_examples.erase(live_examples.find(this));
	}
};

Example somefn()
{
	Example e;
	return e;
}

In this example, guaranteed copy elision means that somefn allocates `e` in the space provided for it in the caller, calling the constructor, which then captures the value. In the generated IR, the space for `e` has the `sret` attribute but it is definitely not nocapture.

You can also trigger this in C, though in the C case it is undefined behaviour. Consider this example:

struct Foo
{
         int a[5];
};

int x(struct Foo *);

struct Foo f(void)
{
         struct Foo foo;
         x(&foo);
         return foo;
}

The source-language semantics guarantee that no pointers to `foo` outlive the invocation of `f`, which implies that `x` must not capture the argument. The optimisers take advantage of the fact that it would be UB to compare the address of foo after the end of `f` to any other allocation and we end up generating this IR after optimisation, eliding the copy:

; Function Attrs: nounwind uwtable
define dso_local void @f(%struct.Foo* noalias sret(%struct.Foo) align 4 %0) local_unnamed_addr #0 {
   %2 = tail call i32 @x(%struct.Foo* %0) #2
   ret void
}

Nothing in the IR says that `x`'s argument is nocapture. Whether this is permitted depends on what we want nocapture to mean. There are two possible interpretations:

  - The callee does not capture the argument, if the callee does capture the argument then the IR is ill-formed and we have a compiler bug.
  - The caller is free to assume that the callee does not capture the argument, if the callee does capture the argument then it is UB.

The former allows the absence of nocapture to be interpreted as 'we can't statically prove that the argument is not captured'. This is very useful for memory-safety work, because it allows us to trust `nocapture` as a security property: we can emit any further analysis.

The latter allows optimisations to be more aggressive but will sometimes generate more surprising code for users and may break some security properties if security-related transforms depend on this information.

My personal bias is towards the former: we would like to be able to use `nocapture` in stack temporal safety work as a strong guarantee. As such, the front end could not insert it because transforms may later insert a capture. Alternatively, the module verifier should be updated to ensure that a nocapture argument is not passed to any other function except via a nocapture argument.

David

I strongly suggest to emit nocapture with sret in the frontend
instead.

I don't think that is actually feasible. For example, consider this C++ file:

#include <set>

struct Example;
std::set<Example*> live_examples;
struct Example {
    Example()
    {
        live_examples.insert(this);
    }
    ~Example()
    {
        live_examples.erase(live_examples.find(this));
    }
};

Example somefn()
{
    Example e;
    return e;
}

In this example, guaranteed copy elision means that somefn allocates `e` in the space provided for it in the caller, calling the constructor, which then captures the value. In the generated IR, the space for `e` has the `sret` attribute but it is definitely not nocapture.

Right, copy elision. But the frontend could still know if it did something that could expose the pointer, e.g., in the C case below.
My initial statement of "sret implies nocapture" is however not true in this case, I had C in mind. I guess "just" deriving nocapture
is the best way to go after all.

You can also trigger this in C, though in the C case it is undefined behaviour. Consider this example:

struct Foo
{
        int a[5];
};

int x(struct Foo *);

struct Foo f(void)
{
        struct Foo foo;
        x(&foo);
        return foo;
}

The source-language semantics guarantee that no pointers to `foo` outlive the invocation of `f`, which implies that `x` must not capture the argument. The optimisers take advantage of the fact that it would be UB to compare the address of foo after the end of `f` to any other allocation and we end up generating this IR after optimisation, eliding the copy:

; Function Attrs: nounwind uwtable
define dso_local void @f(%struct.Foo* noalias sret(%struct.Foo) align 4 %0) local_unnamed_addr #0 {
  %2 = tail call i32 @x(%struct.Foo* %0) #2
  ret void
}

Nothing in the IR says that `x`'s argument is nocapture. Whether this is permitted depends on what we want nocapture to mean. There are two possible interpretations:

- The callee does not capture the argument, if the callee does capture the argument then the IR is ill-formed and we have a compiler bug.
- The caller is free to assume that the callee does not capture the argument, if the callee does capture the argument then it is UB.

The former allows the absence of nocapture to be interpreted as 'we can't statically prove that the argument is not captured'. This is very useful for memory-safety work, because it allows us to trust `nocapture` as a security property: we can emit any further analysis.

The latter allows optimisations to be more aggressive but will sometimes generate more surprising code for users and may break some security properties if security-related transforms depend on this information.

My personal bias is towards the former: we would like to be able to use `nocapture` in stack temporal safety work as a strong guarantee. As such, the front end could not insert it because transforms may later insert a capture. Alternatively, the module verifier should be updated to ensure that a nocapture argument is not passed to any other function except via a nocapture argument.

I don't follow your explanation here, partially because the absence is never "we can't prove", it might just mean, we haven't tried yet.

Given the way we use (almost) all attributes and the fact users can basically write:

void u(int*);
void q(int* __attribute__((noescape) p) { u(p); }

I don't see why `nocapture` would not mean: "assume is not captured, if it is, UB".

That said, if you want to use attributes for security policies, which I see as useful, you need to create new versions.
FWIW, this is not only about `nocapture`. One more thing to consider is that we inherently use UB to argue when it comes
to attribute inference as well as code transformations and thereby implicitly attribute inference on the transformed code.

~ Johannes

end up generating this IR after optimisation

AFAICT, that’s the IR before optimization, as seen from clang -S -emit-llvm -O0 -o - -x c -.

I strongly suggest to emit nocapture with sret in the frontend instead.

It seems like clang -x c doesn’t emit nocapture for even trivial cases I tried (like the above, but without function x). Is that a bug then, or just not applicable to C?

Regardless, I don’t think this should be a verifier error for passing nocapture to maycapture, since it may be valid for a source language to know that a particular use of an argument is nocapture, even if the general function contract doesn’t promise it.

end up generating this IR after optimisation

AFAICT, that's the IR before optimization, as seen from `clang -S
-emit-llvm -O0 -o - -x c -`.

I strongly suggest to emit nocapture with sret in the frontend instead.

It seems like `clang -x c` doesn't emit nocapture for even trivial cases I
tried (like the above, but without function `x`). Is that a bug then, or
just not applicable to C?

I think one of my earlier statement was wrong as sret doesn't imply nocapture
the was we use it. The frontend could know if it does and place nocapture, but
it is not as straight forward as I hoped it would be. Unclear if it is worth
to add the logic to Clang but certainly it is good if frontends emit as many
attributes as possible.

Regardless, I don't think this should be a verifier error for passing
nocapture to maycapture, since it may be valid for a source language to
know that a particular use of an argument is nocapture, even if the general
function contract doesn't promise it.

Agreed. You can do that in C/C++ through clang as well.