[LangRef] Add uniqueptr attribute.

[fhahn]

Summary

This patch adds a new uniqueptr attribute.

The attribute can be used to indicate that an argument is the only
pointer referencing the underlying object based on the pointer.

The intent of this attribute is to provide a guarantee that the no
pointers to the object are escaped before calling the function.

The motivating case is passing indirectly passed arguments on platforms
that do not use byval, like AArch64. On AArch64, objects passed by value
are allocated in the caller and then passed as pointers, but there is no
information in the called function that the argument is the only pointer
to the underlying object.

This currently prohibits some optimizations. The example below is roughly the
IR generated by Clang for a function that takes a struct by value on AArch64.
We cannot remove the second load, because nothing guarantees that %x
did not escape before calling the function. The new attribute provides
exactly this guarantee, allowing us to remove the second load.

%struct.Foo = type { i8*, i8*, i8*, i32 }

define i32 @test(%struct.Foo* nocapture readonly %x) {
entry:
  %x1 = getelementptr inbounds %struct.Foo, %struct.Foo* %x, i64 0, i32 3
  %0 = load i32, i32* %x1, align 8, !tbaa !2
  tail call void bitcast (void (...)* @sideeffect to void ()*)() #2
  %1 = load i32, i32* %x1, align 8, !tbaa !2
  %add = add nsw i32 %1, %0
  ret i32 %add
}

In a way, the uniqueptr attribute should behave similar to byval, just
that the object is allocated in the caller, rather than on the callee
stack.

I am a bit reluctant to add yet another attribute, but unfortunately there
seems to be no combination of attributes that achieves the desired
optimizations.

NoAlias is relatively close, but it is not suitable, because references
to the object can escape in the called function.

I am also not sure about the name of the attribute. Any suggestions for
a better name are more than welcome!

[arsenm]

I think this sounds suspiciously like byref

llvm/include/llvm/IR/Attributes.td

160

Missing comment

llvm/lib/Bitcode/Writer/BitcodeWriter.cpp

742

Missing bitcode and asm parser tests

[fhahn]

Sorry for not being up-front about this, there are still some comments/tests missing, but I'd like to make sure this is going in the right direction first.

[jdoerfert]

As discussed on IRC, I think noalias is actually what you want. Storing a pointer and loading it does *not* break the "based on" relationship (https://llvm.org/docs/LangRef.html#pointeraliasing). We might want to clarify the rules though.

@hfinkel @jeroen.dobbelaere ^ WDYT?

[hfinkel]

We cannot remove the second load, because nothing guarantees that %x did not escape before calling the function. The new attribute provides exactly this guarantee, allowing us to remove the second load.

Why does noalias not provide the relevant guarantee? Even if the pointer had escaped, your call to @sideeffect would not be allowed to access the value through that escaped pointer (unless it were passed as an argument to @sideeffect) because that would violate the rule that all values accessed through a noalias pointer are accessed only through pointers based on the noalias pointer within the scope of the noalias pointer.

[fhahn]

In D84860#2182375, @hfinkel wrote:

We cannot remove the second load, because nothing guarantees that %x did not escape before calling the function. The new attribute provides exactly this guarantee, allowing us to remove the second load.

Why does noalias not provide the relevant guarantee? Even if the pointer had escaped, your call to @sideeffect would not be allowed to access the value through that escaped pointer (unless it were passed as an argument to @sideeffect) because that would violate the rule that all values accessed through a noalias pointer are accessed only through pointers based on the noalias pointer within the scope of the noalias pointer.

I think it boils down to the exact interpretation of noalias for the IR example below. Assume %0 would be marked as noalias. IIUC your comment correctly, @sideffect would not be allowed to modify the underlying object of %0 (this also matches my reading of the based-on rules, with value referring to LLVM IR/SSA value).

%struct.Foo = type { i8*, i8*, i32 }

@PTR = dso_local local_unnamed_addr global %struct.Foo* null, align 8

define dso_local i32 @test(%struct.Foo* %0) local_unnamed_addr #0 {
  %2 = getelementptr inbounds %struct.Foo, %struct.Foo* %0, i64 0, i32 2
  %3 = load i32, i32* %2, align 8, !tbaa !2
  store %struct.Foo* %0, %struct.Foo** @PTR, align 8, !tbaa !8
  tail call void bitcast (void (...)* @sideeffect to void ()*)() #2
  %4 = load i32, i32* %2, align 8, !tbaa !2
  %5 = add nsw i32 %4, %3
  ret i32 %5
}

declare dso_local void @sideeffect(...) local_unnamed_addr #1

If the above is true, then noalias would be too strict, because modifications via an escaped pointer in the function should be allowed with the uniqueptr semantics. IIUC we need to allow modifications, because references to passed-by-value objects can escape and used to modify the object in callees, as in something like the code below, where @sideeffect would be allowed to modify x via PTR

struct Foo *PTR;

int test(struct Foo x) {
    int a = x.i;
    PTR = &x;
    sideeffect();
    return x.i + a;
}

[hfinkel]

In D84860#2182432, @fhahn wrote:

In D84860#2182375, @hfinkel wrote:

We cannot remove the second load, because nothing guarantees that %x did not escape before calling the function. The new attribute provides exactly this guarantee, allowing us to remove the second load.

Why does noalias not provide the relevant guarantee? Even if the pointer had escaped, your call to @sideeffect would not be allowed to access the value through that escaped pointer (unless it were passed as an argument to @sideeffect) because that would violate the rule that all values accessed through a noalias pointer are accessed only through pointers based on the noalias pointer within the scope of the noalias pointer.

I think it boils down to the exact interpretation of noalias for the IR example below. Assume %0 would be marked as noalias. IIUC your comment correctly, @sideffect would not be allowed to modify the underlying object of %0 (this also matches my reading of the based-on rules, with value referring to LLVM IR/SSA value).

%struct.Foo = type { i8*, i8*, i32 }

@PTR = dso_local local_unnamed_addr global %struct.Foo* null, align 8

define dso_local i32 @test(%struct.Foo* %0) local_unnamed_addr #0 {
  %2 = getelementptr inbounds %struct.Foo, %struct.Foo* %0, i64 0, i32 2
  %3 = load i32, i32* %2, align 8, !tbaa !2
  store %struct.Foo* %0, %struct.Foo** @PTR, align 8, !tbaa !8
  tail call void bitcast (void (...)* @sideeffect to void ()*)() #2
  %4 = load i32, i32* %2, align 8, !tbaa !2
  %5 = add nsw i32 %4, %3
  ret i32 %5
}

declare dso_local void @sideeffect(...) local_unnamed_addr #1

If the above is true, then noalias would be too strict, because modifications via an escaped pointer in the function should be allowed with the uniqueptr semantics. IIUC we need to allow modifications, because references to passed-by-value objects can escape and used to modify the object in callees, as in something like the code below, where @sideeffect would be allowed to modify x via PTR

struct Foo *PTR;

int test(struct Foo x) {
    int a = x.i;
    PTR = &x;
    sideeffect();
    return x.i + a;
}

No, that's okay. The "based on" relationship flows through memory as well. The C spec for restrict does a better job than the LangRef does in this respect in formalizing that, but our semantics need to allow this too (otherwise our SSA conversation in SROA/mem2reg would not be sound for noalias pointers). In this case, PTR is based on &x, and accesses through it in sideeffect are allowed even if x is noalias. One of the things that makes handling noalais pointers more-difficult than one might expect is, specifically, that we do need to check for cases where the restrict pointer itself escapes because then any other pointer of unknown provenance might be based on it.

[fhahn]

In D84860#2182487, @hfinkel wrote:

In D84860#2182432, @fhahn wrote:

In D84860#2182375, @hfinkel wrote:

We cannot remove the second load, because nothing guarantees that %x did not escape before calling the function. The new attribute provides exactly this guarantee, allowing us to remove the second load.

Why does noalias not provide the relevant guarantee? Even if the pointer had escaped, your call to @sideeffect would not be allowed to access the value through that escaped pointer (unless it were passed as an argument to @sideeffect) because that would violate the rule that all values accessed through a noalias pointer are accessed only through pointers based on the noalias pointer within the scope of the noalias pointer.

I think it boils down to the exact interpretation of noalias for the IR example below. Assume %0 would be marked as noalias. IIUC your comment correctly, @sideffect would not be allowed to modify the underlying object of %0 (this also matches my reading of the based-on rules, with value referring to LLVM IR/SSA value).

%struct.Foo = type { i8*, i8*, i32 }

@PTR = dso_local local_unnamed_addr global %struct.Foo* null, align 8

define dso_local i32 @test(%struct.Foo* %0) local_unnamed_addr #0 {
  %2 = getelementptr inbounds %struct.Foo, %struct.Foo* %0, i64 0, i32 2
  %3 = load i32, i32* %2, align 8, !tbaa !2
  store %struct.Foo* %0, %struct.Foo** @PTR, align 8, !tbaa !8
  tail call void bitcast (void (...)* @sideeffect to void ()*)() #2
  %4 = load i32, i32* %2, align 8, !tbaa !2
  %5 = add nsw i32 %4, %3
  ret i32 %5
}

declare dso_local void @sideeffect(...) local_unnamed_addr #1

If the above is true, then noalias would be too strict, because modifications via an escaped pointer in the function should be allowed with the uniqueptr semantics. IIUC we need to allow modifications, because references to passed-by-value objects can escape and used to modify the object in callees, as in something like the code below, where @sideeffect would be allowed to modify x via PTR

struct Foo *PTR;

int test(struct Foo x) {
    int a = x.i;
    PTR = &x;
    sideeffect();
    return x.i + a;
}

No, that's okay. The "based on" relationship flows through memory as well. The C spec for restrict does a better job than the LangRef does in this respect in formalizing that, but our semantics need to allow this too (otherwise our SSA conversation in SROA/mem2reg would not be sound for noalias pointers).

Agreed, thanks for confirming.

In this case, PTR is based on &x, and accesses through it in sideeffect are allowed even if x is noalias. One of the things that makes handling noalais pointers more-difficult than one might expect is, specifically, that we do need to check for cases where the restrict pointer itself escapes because then any other pointer of unknown provenance might be based on it.

I guess I am curious how the restrict pointer itself can escape in such a way?

[hfinkel]

In D84860#2182545, @fhahn wrote:

In D84860#2182487, @hfinkel wrote:

In D84860#2182432, @fhahn wrote:

In D84860#2182375, @hfinkel wrote:

We cannot remove the second load, because nothing guarantees that %x did not escape before calling the function. The new attribute provides exactly this guarantee, allowing us to remove the second load.

Why does noalias not provide the relevant guarantee? Even if the pointer had escaped, your call to @sideeffect would not be allowed to access the value through that escaped pointer (unless it were passed as an argument to @sideeffect) because that would violate the rule that all values accessed through a noalias pointer are accessed only through pointers based on the noalias pointer within the scope of the noalias pointer.

I think it boils down to the exact interpretation of noalias for the IR example below. Assume %0 would be marked as noalias. IIUC your comment correctly, @sideffect would not be allowed to modify the underlying object of %0 (this also matches my reading of the based-on rules, with value referring to LLVM IR/SSA value).

%struct.Foo = type { i8*, i8*, i32 }

@PTR = dso_local local_unnamed_addr global %struct.Foo* null, align 8

define dso_local i32 @test(%struct.Foo* %0) local_unnamed_addr #0 {
  %2 = getelementptr inbounds %struct.Foo, %struct.Foo* %0, i64 0, i32 2
  %3 = load i32, i32* %2, align 8, !tbaa !2
  store %struct.Foo* %0, %struct.Foo** @PTR, align 8, !tbaa !8
  tail call void bitcast (void (...)* @sideeffect to void ()*)() #2
  %4 = load i32, i32* %2, align 8, !tbaa !2
  %5 = add nsw i32 %4, %3
  ret i32 %5
}

declare dso_local void @sideeffect(...) local_unnamed_addr #1

If the above is true, then noalias would be too strict, because modifications via an escaped pointer in the function should be allowed with the uniqueptr semantics. IIUC we need to allow modifications, because references to passed-by-value objects can escape and used to modify the object in callees, as in something like the code below, where @sideeffect would be allowed to modify x via PTR

struct Foo *PTR;

int test(struct Foo x) {
    int a = x.i;
    PTR = &x;
    sideeffect();
    return x.i + a;
}

No, that's okay. The "based on" relationship flows through memory as well. The C spec for restrict does a better job than the LangRef does in this respect in formalizing that, but our semantics need to allow this too (otherwise our SSA conversation in SROA/mem2reg would not be sound for noalias pointers).

Agreed, thanks for confirming.

In this case, PTR is based on &x, and accesses through it in sideeffect are allowed even if x is noalias. One of the things that makes handling noalais pointers more-difficult than one might expect is, specifically, that we do need to check for cases where the restrict pointer itself escapes because then any other pointer of unknown provenance might be based on it.

I guess I am curious how the restrict pointer itself can escape in such a way?

What do you mean? Just like in your example, it can be assigned to a global variable (or, it can be assigned to *p, where p is an argument).

[fhahn]

In D84860#2182575, @hfinkel wrote:

No, that's okay. The "based on" relationship flows through memory as well. The C spec for restrict does a better job than the LangRef does in this respect in formalizing that, but our semantics need to allow this too (otherwise our SSA conversation in SROA/mem2reg would not be sound for noalias pointers).

Agreed, thanks for confirming.

In this case, PTR is based on &x, and accesses through it in sideeffect are allowed even if x is noalias. One of the things that makes handling noalais pointers more-difficult than one might expect is, specifically, that we do need to check for cases where the restrict pointer itself escapes because then any other pointer of unknown provenance might be based on it.

I guess I am curious how the restrict pointer itself can escape in such a way?

What do you mean? Just like in your example, it can be assigned to a global variable (or, it can be assigned to *p, where p is an argument).

Oh right, I thought you meant there are cases where escaping is not allowed on the C level, but you meant we need to be careful during alias analysis?

[hfinkel]

In D84860#2182584, @fhahn wrote:

In D84860#2182575, @hfinkel wrote:

No, that's okay. The "based on" relationship flows through memory as well. The C spec for restrict does a better job than the LangRef does in this respect in formalizing that, but our semantics need to allow this too (otherwise our SSA conversation in SROA/mem2reg would not be sound for noalias pointers).

Agreed, thanks for confirming.

In this case, PTR is based on &x, and accesses through it in sideeffect are allowed even if x is noalias. One of the things that makes handling noalais pointers more-difficult than one might expect is, specifically, that we do need to check for cases where the restrict pointer itself escapes because then any other pointer of unknown provenance might be based on it.

I guess I am curious how the restrict pointer itself can escape in such a way?

What do you mean? Just like in your example, it can be assigned to a global variable (or, it can be assigned to *p, where p is an argument).

Oh right, I thought you meant there are cases where escaping is not allowed on the C level, but you meant we need to be careful during alias analysis?

Exactly.

[fhahn]

In D84860#2182596, @hfinkel wrote:

In D84860#2182584, @fhahn wrote:

In D84860#2182575, @hfinkel wrote:

No, that's okay. The "based on" relationship flows through memory as well. The C spec for restrict does a better job than the LangRef does in this respect in formalizing that, but our semantics need to allow this too (otherwise our SSA conversation in SROA/mem2reg would not be sound for noalias pointers).

Agreed, thanks for confirming.

In this case, PTR is based on &x, and accesses through it in sideeffect are allowed even if x is noalias. One of the things that makes handling noalais pointers more-difficult than one might expect is, specifically, that we do need to check for cases where the restrict pointer itself escapes because then any other pointer of unknown provenance might be based on it.

I guess I am curious how the restrict pointer itself can escape in such a way?

What do you mean? Just like in your example, it can be assigned to a global variable (or, it can be assigned to *p, where p is an argument).

Oh right, I thought you meant there are cases where escaping is not allowed on the C level, but you meant we need to be careful during alias analysis?

Exactly.

Ok that makes sense. I thought we disallowed going through memory for based-on, because it would make for simpler analysis, but it would indeed make mem2reg/SROA's handling of noalias invalid.

IICU noalias should work fine for the intended purpose.

llvm/docs/LangRef.rst

``immarg``
     call site or arbitrary function.
 
 ``noundef``
     This attribute applies to parameters and return values. If the value
     representation contains any undefined or poison bits, the behavior is
     undefined. Note that this does not refer to padding introduced by the
     type's storage representation.
 
+``uniqueptr``
+   This attribute applies to pointer arguments. The attribute indicates that
+   the argument is the only pointer referencing the underlying object
+   :ref:`based <pointeraliasing>` on the argument before calling the function.
+   If there are other pointers referencing that underlying object before the
+   function is called, the behavior is undefined.
+
 .. _gc:
 
 Garbage Collector Strategy Names
 --------------------------------
 
 Each function may specify a garbage collector strategy name, which is simply a
 string:
 

llvm/include/llvm/Bitcode/LLVMBitCodes.h

enum AttributeKindCodes {
   ATTR_KIND_NOFREE = 62,
   ATTR_KIND_NOSYNC = 63,
   ATTR_KIND_SANITIZE_MEMTAG = 64,
   ATTR_KIND_PREALLOCATED = 65,
   ATTR_KIND_NO_MERGE = 66,
   ATTR_KIND_NULL_POINTER_IS_VALID = 67,
   ATTR_KIND_NOUNDEF = 68,
   ATTR_KIND_BYREF = 69,
+  ATTR_KIND_UNIQUEPTR = 70,
 };
 
 enum ComdatSelectionKindCodes {
   COMDAT_SELECTION_KIND_ANY = 1,
   COMDAT_SELECTION_KIND_EXACT_MATCH = 2,
   COMDAT_SELECTION_KIND_LARGEST = 3,
   COMDAT_SELECTION_KIND_NO_DUPLICATES = 4,
   COMDAT_SELECTION_KIND_SAME_SIZE = 5,

llvm/include/llvm/IR/Argument.h

public:
   uint64_t getDereferenceableOrNullBytes() const;
 
   /// Return true if this argument has the byval attribute.
   bool hasByValAttr() const;
 
   /// Return true if this argument has the byref attribute.
   bool hasByRefAttr() const;
 
+  bool hasUniquePtrAttr() const;
+
   /// Return true if this argument has the swiftself attribute.
   bool hasSwiftSelfAttr() const;
 
   /// Return true if this argument has the swifterror attribute.
   bool hasSwiftErrorAttr() const;
 
   /// Return true if this argument has the byval, inalloca, or preallocated
   /// attribute. These attributes represent arguments being passed by value,

llvm/include/llvm/IR/Attributes.td

 def ReadNone : EnumAttr<"readnone">;
 
 /// Function only reads from memory.
 def ReadOnly : EnumAttr<"readonly">;
 
 /// Return value is always equal to this argument.
 def Returned : EnumAttr<"returned">;
 
+def UniquePtr: EnumAttr<"uniqueptr">;
+
 /// Parameter is required to be a trivial constant.
 def ImmArg : EnumAttr<"immarg">;
 
 /// Function can return twice.
 def ReturnsTwice : EnumAttr<"returns_twice">;
 
 /// Safe Stack protection.
 def SafeStack : EnumAttr<"safestack">;

llvm/lib/Analysis/BasicAliasAnalysis.cpp

if (IsCapturedCache)
       CacheIt->second = Ret;
     return Ret;
   }
 
   // If this is an argument that corresponds to a byval or noalias argument,
   // then it has not escaped before entering the function.  Check if it escapes
   // inside the function.
   if (const Argument *A = dyn_cast<Argument>(V))
-    if (A->hasByValAttr() || A->hasNoAliasAttr()) {
+    if (A->hasByValAttr() || A->hasNoAliasAttr() || A->hasUniquePtrAttr()) {
       // Note even if the argument is marked nocapture, we still need to check
       // for copies made inside the function. The nocapture attribute only
       // specifies that there are no copies made that outlive the function.
       auto Ret = !PointerMayBeCaptured(V, false, /*StoreCaptures=*/true);
       if (IsCapturedCache)
         CacheIt->second = Ret;
       return Ret;
     }

llvm/lib/AsmParser/LLLexer.cpp

#define KEYWORD(STR)                                                           \
   KEYWORD(swifterror);
   KEYWORD(swiftself);
   KEYWORD(uwtable);
   KEYWORD(willreturn);
   KEYWORD(writeonly);
   KEYWORD(zeroext);
   KEYWORD(immarg);
   KEYWORD(byref);
+  KEYWORD(uniqueptr);
 
   KEYWORD(type);
   KEYWORD(opaque);
 
   KEYWORD(comdat);
 
   // Comdat types
   KEYWORD(any);

llvm/lib/AsmParser/LLParser.cpp

while (true) {
     case lltok::kw_nocapture:
     case lltok::kw_nonnull:
     case lltok::kw_returned:
     case lltok::kw_sret:
     case lltok::kw_swifterror:
     case lltok::kw_swiftself:
     case lltok::kw_immarg:
     case lltok::kw_byref:
+    case lltok::kw_uniqueptr:
       HaveError |=
         Error(Lex.getLoc(),
               "invalid use of parameter-only attribute on a function");
       break;
     }
 
     // ParsePreallocated() consumes token
     if (Token != lltok::kw_preallocated)
while (true) {
     }
     case lltok::kw_byref: {
       Type *Ty;
       if (ParseByRef(Ty))
         return true;
       B.addByRefAttr(Ty);
       continue;
     }
+    case lltok::kw_uniqueptr:       B.addAttribute(Attribute::UniquePtr); break;
     case lltok::kw_inalloca:        B.addAttribute(Attribute::InAlloca); break;
     case lltok::kw_inreg:           B.addAttribute(Attribute::InReg); break;
     case lltok::kw_nest:            B.addAttribute(Attribute::Nest); break;
     case lltok::kw_noundef:
       B.addAttribute(Attribute::NoUndef);
       break;
     case lltok::kw_noalias:         B.addAttribute(Attribute::NoAlias); break;
     case lltok::kw_nocapture:       B.addAttribute(Attribute::NoCapture); break;
while (true) {
     case lltok::kw_nest:
     case lltok::kw_nocapture:
     case lltok::kw_returned:
     case lltok::kw_sret:
     case lltok::kw_swifterror:
     case lltok::kw_swiftself:
     case lltok::kw_immarg:
     case lltok::kw_byref:
+    case lltok::kw_uniqueptr:
       HaveError |= Error(Lex.getLoc(), "invalid use of parameter-only attribute");
       break;
 
     case lltok::kw_alignstack:
     case lltok::kw_alwaysinline:
     case lltok::kw_argmemonly:
     case lltok::kw_builtin:
     case lltok::kw_cold:

llvm/lib/AsmParser/LLToken.h

enum Kind {
   kw_swifterror,
   kw_swiftself,
   kw_uwtable,
   kw_willreturn,
   kw_writeonly,
   kw_zeroext,
   kw_immarg,
   kw_byref,
+  kw_uniqueptr,
 
   kw_type,
   kw_opaque,
 
   kw_comdat,
 
   // Comdat types
   kw_any,

llvm/lib/Bitcode/Reader/BitcodeReader.cpp

static Attribute::AttrKind getAttrFromCode(uint64_t Code) {
   case bitc::ATTR_KIND_SANITIZE_MEMTAG:
     return Attribute::SanitizeMemTag;
   case bitc::ATTR_KIND_PREALLOCATED:
     return Attribute::Preallocated;
   case bitc::ATTR_KIND_NOUNDEF:
     return Attribute::NoUndef;
   case bitc::ATTR_KIND_BYREF:
     return Attribute::ByRef;
+  case bitc::ATTR_KIND_UNIQUEPTR:
+    return Attribute::UniquePtr;
+
   }
 }
 
 Error BitcodeReader::parseAlignmentValue(uint64_t Exponent,
                                          MaybeAlign &Alignment) {
   // Note: Alignment in bitcode files is incremented by 1, so that zero
   // can be used for default alignment.
   if (Exponent > Value::MaxAlignmentExponent + 1)

llvm/lib/Bitcode/Writer/BitcodeWriter.cpp

static uint64_t getAttrKindEncoding(Attribute::AttrKind Kind) {
   case Attribute::SanitizeMemTag:
     return bitc::ATTR_KIND_SANITIZE_MEMTAG;
   case Attribute::Preallocated:
     return bitc::ATTR_KIND_PREALLOCATED;
   case Attribute::NoUndef:
     return bitc::ATTR_KIND_NOUNDEF;
   case Attribute::ByRef:
     return bitc::ATTR_KIND_BYREF;
+  case Attribute::UniquePtr:
+    return bitc::ATTR_KIND_UNIQUEPTR;
+
   case Attribute::EndAttrKinds:
     llvm_unreachable("Can not encode end-attribute kinds marker.");
   case Attribute::None:
     llvm_unreachable("Can not encode none-attribute.");
   case Attribute::EmptyKey:
   case Attribute::TombstoneKey:
     llvm_unreachable("Trying to encode EmptyKey/TombstoneKey");
   }

llvm/lib/IR/Attributes.cpp

std::string Attribute::getAsString(bool InAttrGrp) const {
   if (hasAttribute(Attribute::ZExt))
     return "zeroext";
   if (hasAttribute(Attribute::Cold))
     return "cold";
   if (hasAttribute(Attribute::ImmArg))
     return "immarg";
   if (hasAttribute(Attribute::NoUndef))
     return "noundef";
+  if (hasAttribute(Attribute::UniquePtr))
+      return "uniqueptr";
 
   if (hasAttribute(Attribute::ByVal)) {
     std::string Result;
     Result += "byval";
     if (Type *Ty = getValueAsType()) {
       raw_string_ostream OS(Result);
       Result += '(';
       Ty->print(OS, false, true);

llvm/lib/IR/Function.cpp

 }
 
 bool Argument::hasByRefAttr() const {
   if (!getType()->isPointerTy())
     return false;
   return hasAttribute(Attribute::ByRef);
 }
 
+bool Argument::hasUniquePtrAttr() const {
+  if (!getType()->isPointerTy())
+    return false;
+  return hasAttribute(Attribute::UniquePtr);
+}
+
+
 bool Argument::hasSwiftSelfAttr() const {
   return getParent()->hasParamAttribute(getArgNo(), Attribute::SwiftSelf);
 }
 
 bool Argument::hasSwiftErrorAttr() const {
   return getParent()->hasParamAttribute(getArgNo(), Attribute::SwiftError);
 }
 

llvm/test/Transforms/EarlyCSE/uniqueptr.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -early-cse-memssa -S %s | FileCheck %s
+
+target datalayout = "e-m:e-i64:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+
+%struct = type { i64, i64, i64 }
+
+; uniqueptr guarantees there are pointers other than %arg pointing to %arg's
+; underlying object. So external_effect cannot modify the object and the second
+; load can be removed.
+define i64 @test_noescape(%struct * uniqueptr %arg) {
+; CHECK-LABEL: @test_noescape(
+; CHECK-NEXT:    [[ARG_F0:%.*]] = getelementptr inbounds [[STRUCT:%.*]], %struct* [[ARG:%.*]], i64 0, i32 0
+; CHECK-NEXT:    [[L_0_ARG_F0:%.*]] = load i64, i64* [[ARG_F0]], align 8
+; CHECK-NEXT:    call void @external_effect()
+; CHECK-NEXT:    [[RES:%.*]] = add i64 [[L_0_ARG_F0]], [[L_0_ARG_F0]]
+; CHECK-NEXT:    ret i64 [[RES]]
+;
+  %arg.f0 = getelementptr inbounds %struct, %struct* %arg, i64 0, i32 0
+  %l.0.arg.f0 = load i64, i64* %arg.f0, align 8
+  call void @external_effect()
+  %l.1.arg.f0 = load i64, i64* %arg.f0, align 8
+  %res = add i64 %l.1.arg.f0, %l.0.arg.f0
+  ret i64 %res
+}
+
[e-mail] = global %struct* null, align 8
+
+; Cannot remove the second load, because %arg escapes before calling
+; @external_effect.
+define i64 @test_escape_before_call(%struct * uniqueptr %arg) {
+; CHECK-LABEL: @test_escape_before_call(
+; CHECK-NEXT:    [[ARG_F0:%.*]] = getelementptr inbounds [[STRUCT:%.*]], %struct* [[ARG:%.*]], i64 0, i32 0
+; CHECK-NEXT:    [[L_0_ARG_F0:%.*]] = load i64, i64* [[ARG_F0]], align 8
+; CHECK-NEXT:    store %struct* [[ARG]], %struct** @global.ptr, align 8
+; CHECK-NEXT:    call void @external_effect()
+; CHECK-NEXT:    [[L_1_ARG_F0:%.*]] = load i64, i64* [[ARG_F0]], align 8
+; CHECK-NEXT:    [[RES:%.*]] = add i64 [[L_1_ARG_F0]], [[L_0_ARG_F0]]
+; CHECK-NEXT:    ret i64 [[RES]]
+;
+  %arg.f0 = getelementptr inbounds %struct, %struct* %arg, i64 0, i32 0
+  %l.0.arg.f0 = load i64, i64* %arg.f0, align 8
+  store %struct* %arg, %struct** @global.ptr
+  call void @external_effect()
+  %l.1.arg.f0 = load i64, i64* %arg.f0, align 8
+  %res = add i64 %l.1.arg.f0, %l.0.arg.f0
+  ret i64 %res
+}
+
+declare void @external_effect()