align_value attribute in Clang

[hfinkel]

Summary

This patch introduces support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code.

Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this:

typedef double aligned_double attribute((aligned(64)));
void foo(aligned_double *P) {

double x = P[0]; // This is fine.
double y = P[1]; // What alignment did those doubles have again?

}

the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad.

With the align_value attribute, we can accomplish what we'd like in a well defined way:
typedef double *aligned_double_ptr attribute((align_value(64)));
void foo(aligned_double_ptr P) {

double x = P[0]; // This is fine.
double y = P[1]; // This is fine too.

}

This patch is not predicated on any uncommitted LLVM features -- CodeGen just adds the align attribute on function arguments, which has the desired effect as of r213670 -- (although, as follow-up work, can be enhanced to apply to more than just function parameters when combined with the in-development llvm.assume functionality).

Some documentation on the align_value attribute from Intel is on this page:
https://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization

Thanks again!

P.S. I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name.

[rsmith]

+Michael Spencer, he was considering proposing something similar for standardization.

[hfinkel]

One aspect perhaps worth some thought:

typedef double * aligned_double_ptr attribute((align_value(64)));
aligned_double_ptr x;

void foo(decltype(x + 3) y, aligned_double_ptr z) {}

Does y also carry the alignment assumption? As it stands in my current patch, the answer is no -- I think that is the desirable outcome, but I could be convinced otherwise ;)

Thanks again,
Hal

• Original Message -----

From: "Richard Smith" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Sent: Tuesday, July 22, 2014 9:18:56 PM
Subject: Re: [PATCH] align_value attribute in Clang

+Michael Spencer, he was considering proposing something similar for
standardization.

http://reviews.llvm.org/D4635

[ABataev]

In icc this attribute is inherited.

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team
Intel Corp.

23.07.2014 10:13, Hal Finkel пишет:

One aspect perhaps worth some thought:

typedef double * aligned_double_ptr attribute((align_value(64)));
aligned_double_ptr x;

void foo(decltype(x + 3) y, aligned_double_ptr z) {}

Does y also carry the alignment assumption? As it stands in my current patch, the answer is no -- I think that is the desirable outcome, but I could be convinced otherwise ;)

Thanks again,
Hal

• Original Message -----

From: "Richard Smith" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Sent: Tuesday, July 22, 2014 9:18:56 PM
Subject: Re: [PATCH] align_value attribute in Clang

+Michael Spencer, he was considering proposing something similar for
standardization.

http://reviews.llvm.org/D4635

[hfinkel]

• Original Message -----

From: "Alexey Bataev" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail], "a
bataev" <[e-mail]>
Cc: [e-mail]
Sent: Wednesday, July 23, 2014 3:43:25 AM
Subject: Re: [PATCH] align_value attribute in Clang

In icc this attribute is inherited.

Interestingly, I made this:

def AlignValue : InheritableAttr

but I suppose that does not do this?

-Hal

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team
Intel Corp.

23.07.2014 10:13, Hal Finkel пишет:

One aspect perhaps worth some thought:

typedef double * aligned_double_ptr
attribute((align_value(64)));
aligned_double_ptr x;

void foo(decltype(x + 3) y, aligned_double_ptr z) {}

Does y also carry the alignment assumption? As it stands in my
current patch, the answer is no -- I think that is the desirable
outcome, but I could be convinced otherwise ;)

Thanks again,
Hal

• Original Message -----

From: "Richard Smith" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>,
[e-mail], [e-mail]
Cc: [e-mail]
Sent: Tuesday, July 22, 2014 9:18:56 PM
Subject: Re: [PATCH] align_value attribute in Clang

+Michael Spencer, he was considering proposing something similar
for
standardization.

http://reviews.llvm.org/D4635

http://reviews.llvm.org/D4635

[ABataev]

Hal,
probably you should add processing of this attribute to function
mergeDeclAttribute() in SemaDecl.cpp or something like this.

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team

23 Июль 2014 г. 19:22:35, [e-mail] писал:

• Original Message -----

From: "Alexey Bataev" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail], "a
bataev" <[e-mail]>
Cc: [e-mail]
Sent: Wednesday, July 23, 2014 3:43:25 AM
Subject: Re: [PATCH] align_value attribute in Clang

In icc this attribute is inherited.

Interestingly, I made this:

def AlignValue : InheritableAttr

but I suppose that does not do this?

-Hal

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team
Intel Corp.

23.07.2014 10:13, Hal Finkel пишет:

One aspect perhaps worth some thought:

typedef double * aligned_double_ptr
attribute((align_value(64)));
aligned_double_ptr x;

void foo(decltype(x + 3) y, aligned_double_ptr z) {}

Does y also carry the alignment assumption? As it stands in my
current patch, the answer is no -- I think that is the desirable
outcome, but I could be convinced otherwise ;)

Thanks again,
Hal

• Original Message -----

From: "Richard Smith" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>,
[e-mail], [e-mail]
Cc: [e-mail]
Sent: Tuesday, July 22, 2014 9:18:56 PM
Subject: Re: [PATCH] align_value attribute in Clang

+Michael Spencer, he was considering proposing something similar
for
standardization.

http://reviews.llvm.org/D4635

http://reviews.llvm.org/D4635

http://reviews.llvm.org/D4635

[hfinkel]

An updated patch, accounting for review comments -- but this does not yet properly treat the attribute as a type attribute (so that it will be inherited by auto, etc.). I still need to work on that aspect, and I'll post another revision once I have those semantics working.

[hfinkel]

Rebased, and removed from inappropriate isTypeDependent/isValueDependent checks (inappropriate here for the same reason they were inappropriate in patch D4601 for the assume_aligned attribute).

Work still needs to be done to allow use as a type attribute (so that the attribute follows type deduction, auto, etc.). I'll send a follow-up e-mail about this with questions.

[hfinkel]

• Original Message -----

From: [e-mail]
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail], "a
bataev" <[e-mail]>
Cc: [e-mail], "nurmukhametov alex" <[e-mail]>
Sent: Monday, September 8, 2014 6:38:44 PM
Subject: Re: [PATCH] align_value attribute in Clang

Rebased, and removed from inappropriate
isTypeDependent/isValueDependent checks (inappropriate here for the
same reason they were inappropriate in patch D4601 for the
assume_aligned attribute).

Work still needs to be done to allow use as a type attribute (so that
the attribute follows type deduction, auto, etc.). I'll send a
follow-up e-mail about this with questions.

I need this attribute to follow type deduction (auto, etc.), and as we've discussed, just making this a declaration attribute does not seem to do this. It seems to me that what I need to do, or at least might do, is hook align_value into AttributedType, and handle it in lib/Sema/SemaType.cpp. First, it is not clear where I should store the alignment parameter:

• address_space stores its value in the type qualifiers
• reg_parm stores its value as part of FunctionType
• vector_type / ext_vector_type are their own Type subclasses (where ExtVectorType is a subclass of VectorType, but there is also DependentSizedExtVectorType which handles dependent attributes).

Given that align_value also needs to handle dependent alignment values, that seems most like the ExtVectorType/DependentSizedExtVectorType setup. I could create AlignValuePointerType/DependentAlignValuePointerType (or similar), maybe with AlignValuePointerType being a subclass of PointerType? (or maybe both being subclasses of PointerType?)

That having been said, creating subclasses of PointerType and/or new Type subclasses seems like an unfortunate amount of infrastructure for this feature. An alternative would be to place extra data directly into PointerType, but I don't like that idea because it adds memory (and some runtime) overhead to the common case with no corresponding benefit.

Ideally, I'd be able to use the original AlignValueAttr nodes, perhaps in combination with AttributedType somehow to indicate that a relevant AlignValueAttr node exists somewhere. Is there a way to do this?

In short, I'm not sure what the best way of doing this is, and I'm looking for advice.

Thanks again,
Hal

http://reviews.llvm.org/D4635

Files:

include/clang/Basic/Attr.td
include/clang/Basic/AttrDocs.td
include/clang/Basic/DiagnosticSemaKinds.td
include/clang/Sema/AttributeList.h
include/clang/Sema/Sema.h
lib/CodeGen/CGCall.cpp
lib/Sema/SemaDeclAttr.cpp
lib/Sema/SemaTemplateInstantiateDecl.cpp
test/CodeGen/align_value.cpp
test/Sema/align_value.c
test/SemaCXX/align_value.cpp

[hfinkel]

• Original Message -----

From: "Hal Finkel" <[e-mail]>
To: [e-mail]
Cc: "a bataev" <[e-mail]>, "nurmukhametov alex" <[e-mail]>, "aaron ballman"
<[e-mail]>, [e-mail], [e-mail]
Sent: Monday, September 8, 2014 6:59:07 PM
Subject: Re: [PATCH] align_value attribute in Clang

• Original Message -----

From: [e-mail]
To: [e-mail], "aaron ballman" <[e-mail]>,
[e-mail], [e-mail], "a
bataev" <[e-mail]>
Cc: [e-mail], "nurmukhametov alex"
<[e-mail]>
Sent: Monday, September 8, 2014 6:38:44 PM
Subject: Re: [PATCH] align_value attribute in Clang

Rebased, and removed from inappropriate
isTypeDependent/isValueDependent checks (inappropriate here for the
same reason they were inappropriate in patch D4601 for the
assume_aligned attribute).

Work still needs to be done to allow use as a type attribute (so
that
the attribute follows type deduction, auto, etc.). I'll send a
follow-up e-mail about this with questions.

Pinging re: the design question below.

Thanks again,
Hal

I need this attribute to follow type deduction (auto, etc.), and as
we've discussed, just making this a declaration attribute does not
seem to do this. It seems to me that what I need to do, or at least
might do, is hook align_value into AttributedType, and handle it in
lib/Sema/SemaType.cpp. First, it is not clear where I should store
the alignment parameter:

• address_space stores its value in the type qualifiers
• reg_parm stores its value as part of FunctionType
• vector_type / ext_vector_type are their own Type subclasses (where ExtVectorType is a subclass of VectorType, but there is also DependentSizedExtVectorType which handles dependent attributes).

Given that align_value also needs to handle dependent alignment
values, that seems most like the
ExtVectorType/DependentSizedExtVectorType setup. I could create
AlignValuePointerType/DependentAlignValuePointerType (or similar),
maybe with AlignValuePointerType being a subclass of PointerType?
(or maybe both being subclasses of PointerType?)

That having been said, creating subclasses of PointerType and/or new
Type subclasses seems like an unfortunate amount of infrastructure
for this feature. An alternative would be to place extra data
directly into PointerType, but I don't like that idea because it
adds memory (and some runtime) overhead to the common case with no
corresponding benefit.

Ideally, I'd be able to use the original AlignValueAttr nodes,
perhaps in combination with AttributedType somehow to indicate that
a relevant AlignValueAttr node exists somewhere. Is there a way to
do this?

In short, I'm not sure what the best way of doing this is, and I'm
looking for advice.

Thanks again,
Hal

http://reviews.llvm.org/D4635

Files:

include/clang/Basic/Attr.td
include/clang/Basic/AttrDocs.td
include/clang/Basic/DiagnosticSemaKinds.td
include/clang/Sema/AttributeList.h
include/clang/Sema/Sema.h
lib/CodeGen/CGCall.cpp
lib/Sema/SemaDeclAttr.cpp
lib/Sema/SemaTemplateInstantiateDecl.cpp
test/CodeGen/align_value.cpp
test/Sema/align_value.c
test/SemaCXX/align_value.cpp

Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

---

cfe-commits mailing list
[e-mail]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[rsmith]

I'd like some more information about how ICC treats this attribute. Does it produce a new type? For instance:

typedef int *I32 __attribute__((align_value(32)));
typedef int *I64 __attribute__((align_value(64)));

typedef I32 X; typedef I64 X; // ill-formed?
template<typename> struct Y;
typedef Y<I32> Z; typedef Y<I64> Z; // ill-formed?

extern I32 i32;
I64 i64 = i32; // ill-formed? Is an explicit cast required?
I32 i32 = i64; // ill-formed? Is there an implicit conversion that discards alignment?

... and if there's an implicit conversion that discards alignment, what is its conversion rank?

If I have:

int n __attribute__((aligned(32)));

... then what is decltype(&n)? Is it int*, or int* __attribute__((align_value(32)))?

[hfinkel]

• Original Message -----

From: "Richard Smith" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail], "a
bataev" <[e-mail]>
Cc: [e-mail]
Sent: Thursday, September 25, 2014 7:06:33 PM
Subject: Re: [PATCH] align_value attribute in Clang

I'd like some more information about how ICC treats this attribute.
Does it produce a new type? For instance:

I did a quick experiment with icc (ICC) 14.0.1 20131008 (with -Wall -O3 -pedantic):

typedef int *I32 __attribute__((align_value(32)));
typedef int *I64 __attribute__((align_value(64)));

typedef I32 X; typedef I64 X; // ill-formed?

No diagnostic.

template<typename> struct Y;
typedef Y<I32> Z; typedef Y<I64> Z; // ill-formed?

No diagnostic.

extern I32 i32;
I64 i64 = i32; // ill-formed? Is an explicit cast required?

No diagnostic.

I32 i32 = i64; // ill-formed? Is there an implicit conversion that
discards alignment?

No diagnostic.

Alexey, can you please comment on the specifics?

-Hal

... and if there's an implicit conversion that discards alignment,
what is its conversion rank?

If I have:

int n __attribute__((aligned(32)));

... then what is decltype(&n)? Is it int*, or `int*
attribute((align_value(32)))`?

http://reviews.llvm.org/D4635

[ABataev]

1. ICC does not create a new type for type with this attribute. All

types are still the same.

int n attribute((aligned(32)));
decltype(&n) - int*.

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team

26.09.2014 4:28, Hal Finkel пишет:

• Original Message -----

From: "Richard Smith" <[e-mail]>
To: [e-mail], "aaron ballman" <[e-mail]>, [e-mail], [e-mail], "a
bataev" <[e-mail]>
Cc: [e-mail]
Sent: Thursday, September 25, 2014 7:06:33 PM
Subject: Re: [PATCH] align_value attribute in Clang

I'd like some more information about how ICC treats this attribute.
Does it produce a new type? For instance:

I did a quick experiment with icc (ICC) 14.0.1 20131008 (with -Wall -O3 -pedantic):

typedef int *I32 __attribute__((align_value(32)));
typedef int *I64 __attribute__((align_value(64)));

typedef I32 X; typedef I64 X; // ill-formed?

No diagnostic.

template<typename> struct Y;
typedef Y<I32> Z; typedef Y<I64> Z; // ill-formed?

No diagnostic.

extern I32 i32;
I64 i64 = i32; // ill-formed? Is an explicit cast required?

No diagnostic.

I32 i32 = i64; // ill-formed? Is there an implicit conversion that
discards alignment?

No diagnostic.

Alexey, can you please comment on the specifics?

-Hal

... and if there's an implicit conversion that discards alignment,
what is its conversion rank?

If I have:

int n __attribute__((aligned(32)));

... then what is decltype(&n)? Is it int*, or `int*
attribute((align_value(32)))`?

http://reviews.llvm.org/D4635

[hfinkel]

Alright, after much discussion, I think this is ready.

To quickly recap, there had been some discussion regarding whether or not align_value needed to be part of the type system (so that it would be propagated by template type deduction, for example), after after receiving feedback from Richard, Alexey, et al., we're settled on no. This is not part of the type system, and will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation.

Aaron, this new revision should account for all additional points from your last review.

[hfinkel]

r218910, thanks!

include/clang/Basic/Attr.td

//  let Subjects = SubjectList<[NonBitField, NormalVar, Tag]>;
   let Accessors = [Accessor<"isGNU", [GCC<"aligned">]>,
                    Accessor<"isC11", [Keyword<"_Alignas">]>,
                    Accessor<"isAlignas", [Keyword<"alignas">,
                                           Keyword<"_Alignas">]>,
                    Accessor<"isDeclspec",[Declspec<"align">]>];
   let Documentation = [Undocumented];
 }
 
+def AlignValue : Attr {
+  let Spellings = [
+                   // Unfortunately, this is semantically an assertion, not a
+                   // directive (something else must ensure the alignment), so
+                   // aligned_value is a probably a better name. We might want
+                   // to add an aligned_value spelling in the future (and a
+                   // corresponding C++ attribute), but this can be done later
+                   // once we decide if we also want them to have
+                   // slightly-different semantics than Intel's align_value.
+                   GNU<"align_value">
+                   // Intel's compiler on Windows also supports:
+                   // , Declspec<"align_value">
+                  ];
+  let Args = [ExprArgument<"Alignment">];
+  let Subjects = SubjectList<[Var, TypedefName], WarnDiag,
+                             "ExpectedVariableOrTypedef">;
+  let Documentation = [AlignValueDocs];
+}
+
 def AlignMac68k : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];
   let SemaHandler = 0;
   let Documentation = [Undocumented];
 }
 
 def AlwaysInline : InheritableAttr {

include/clang/Basic/AttrDocs.td

.. code-block:: c
      }
 
    In this case Clang does not warn because the format string ``s`` and
    the corresponding arguments are annotated.  If the arguments are
    incorrect, the caller of ``foo`` will receive a warning.
   }];
 }
 
+def AlignValueDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The align_value attribute can be added to the typedef of a pointer type or the
+declaration of a variable of pointer or reference type. It specifies that the
+pointer will point to, or the reference will bind to, only objects with at
+least the provided alignment. This alignment value must be some positive power
+of 2.
+
+   .. code-block:: c
+
+     typedef double * aligned_double_ptr __attribute__((align_value(64)));
+     void foo(double & x  __attribute__((align_value(128)),
+              aligned_double_ptr y) { ... }
+
+If the pointer value does not have the specified alignment at runtime, the
+behavior of the program is undefined.
+  }];
+}
+
 def MSInheritanceDocs : Documentation {
   let Category = DocCatType;
   let Heading = "__single_inhertiance, __multiple_inheritance, __virtual_inheritance";
   let Content = [{
 This collection of keywords is enabled under ``-fms-extensions`` and controls
 the pointer-to-member representation used on ``*-*-win32`` targets.
 
 The ``*-*-win32`` targets utilize a pointer-to-member representation which

include/clang/Basic/DiagnosticSemaKinds.td

def err_attribute_too_many_arguments : Error<
   "%0 attribute takes no more than %1 argument%s1">;
 def err_attribute_too_few_arguments : Error<
   "%0 attribute takes at least %1 argument%s1">;
 def err_attribute_invalid_vector_type : Error<"invalid vector element type %0">;
 def err_attribute_bad_neon_vector_size : Error<
   "Neon vector size must be 64 or 128 bits">;
 def err_attribute_unsupported : Error<
   "%0 attribute is not supported for this target">;
+// The err_*_attribute_argument_not_int are seperate because they're used by
+// VerifyIntegerConstantExpression.
 def err_aligned_attribute_argument_not_int : Error<
   "'aligned' attribute requires integer constant">;
+def err_align_value_attribute_argument_not_int : Error<
+  "'align_value' attribute requires integer constant">;
 def err_alignas_attribute_wrong_decl_type : Error<
   "%0 attribute cannot be applied to a %select{function parameter|"
   "variable with 'register' storage class|'catch' variable|bit-field}1">;
 def err_alignas_missing_on_definition : Error<
   "%0 must be specified on definition if it is specified on any declaration">;
 def note_alignas_on_declaration : Note<"declared with %0 attribute here">;
 def err_alignas_mismatch : Error<
   "redeclaration has different alignment requirement (%1 vs %0)">;
def warn_attribute_pointers_only : Warning<
   InGroup<IgnoredAttributes>;
 def err_attribute_pointers_only : Error<warn_attribute_pointers_only.Text>;
 def warn_attribute_return_pointers_only : Warning<
   "%0 attribute only applies to return values that are pointers">,
   InGroup<IgnoredAttributes>;
 def warn_attribute_return_pointers_refs_only : Warning<
   "%0 attribute only applies to return values that are pointers or references">,
   InGroup<IgnoredAttributes>;
+def warn_attribute_pointer_or_reference_only : Warning<
+  "%0 attribute only applies to a pointer or reference (%1 is invalid)">,
+  InGroup<IgnoredAttributes>;
 def err_attribute_no_member_pointers : Error<
   "%0 attribute cannot be used with pointers to members">;
 def err_attribute_invalid_implicit_this_argument : Error<
   "%0 attribute is invalid for the implicit this argument">;
 def err_ownership_type : Error<
   "%0 attribute only applies to %select{pointer|integer}1 arguments">;
 def err_ownership_returns_index_mismatch : Error<
   "'ownership_returns' attribute index does not match; here it is %0">;

 def err_cyclic_alias : Error<
   "alias definition is part of a cycle">;
 def warn_attribute_wrong_decl_type : Warning<
   "%0 attribute only applies to %select{functions|unions|"
   "variables and functions|functions and methods|parameters|"
   "functions, methods and blocks|functions, methods, and classes|"
   "functions, methods, and parameters|classes|variables|methods|"
   "variables, functions and labels|fields and global variables|structs|"
-  "variables, functions and tag types|thread-local variables|"
+  "variables and typedefs|thread-local variables|"
   "variables and fields|variables, data members and tag types|"
   "types and namespaces|Objective-C interfaces|methods and properties|"
   "struct or union|struct, union or class|types|"
   "Objective-C instance methods|init methods of interface or class extension declarations|"
   "variables, functions and classes|Objective-C protocols|"
   "functions and global variables|structs or typedefs|"
   "interface or protocol declarations}1">,
   InGroup<IgnoredAttributes>;

include/clang/Sema/AttributeList.h

enum AttributeDeclKind {
   ExpectedFunctionMethodOrClass,
   ExpectedFunctionMethodOrParameter,
   ExpectedClass,
   ExpectedVariable,
   ExpectedMethod,
   ExpectedVariableFunctionOrLabel,
   ExpectedFieldOrGlobalVar,
   ExpectedStruct,
-  ExpectedVariableFunctionOrTag,
+  ExpectedVariableOrTypedef,
   ExpectedTLSVar,
   ExpectedVariableOrField,
   ExpectedVariableFieldOrTag,
   ExpectedTypeOrNamespace,
   ExpectedObjectiveCInterface,
   ExpectedMethodOrProperty,
   ExpectedStructOrUnion,
   ExpectedStructOrUnionOrClass,

include/clang/Sema/Sema.h

   void AddAlignedAttr(SourceRange AttrRange, Decl *D, TypeSourceInfo *T,
                       unsigned SpellingListIndex, bool IsPackExpansion);
 
   /// AddAssumeAlignedAttr - Adds an assume_aligned attribute to a particular
   /// declaration.
   void AddAssumeAlignedAttr(SourceRange AttrRange, Decl *D, Expr *E, Expr *OE,
                             unsigned SpellingListIndex);
 
+  /// AddAlignValueAttr - Adds an align_value attribute to a particular
+  /// declaration.
+  void AddAlignValueAttr(SourceRange AttrRange, Decl *D, Expr *E,
+                         unsigned SpellingListIndex);
+
   // OpenMP directives and clauses.
 private:
   void *VarDataSharingAttributesStack;
   /// \brief Initialization of data-sharing attributes stack.
   void InitDataSharingAttributesStack();
   void DestroyDataSharingAttributesStack();
   ExprResult VerifyPositiveIntegerConstantInClause(Expr *Op,
                                                    OpenMPClauseKind CKind);

lib/CodeGen/CGCall.cpp

case ABIArgInfo::Direct: {
             // we can't use the dereferenceable attribute, but in addrspace(0)
             // we know that it must be nonnull.
             if (ArrTy->getSizeModifier() == VariableArrayType::Static &&
                 !getContext().getTargetAddressSpace(ArrTy->getElementType()))
               AI->addAttr(llvm::AttributeSet::get(getLLVMContext(),
                                                   AI->getArgNo() + 1,
                                                   llvm::Attribute::NonNull));
           }
+
+          const auto *AVAttr = PVD->getAttr<AlignValueAttr>();
+          if (!AVAttr)
+            if (const auto *TOTy = dyn_cast<TypedefType>(OTy))
+              AVAttr = TOTy->getDecl()->getAttr<AlignValueAttr>();
+          if (AVAttr) {         
+            llvm::Value *AlignmentValue =
+              EmitScalarExpr(AVAttr->getAlignment());
+            llvm::ConstantInt *AlignmentCI =
+              cast<llvm::ConstantInt>(AlignmentValue);
+            unsigned Alignment =
+              std::min((unsigned) AlignmentCI->getZExtValue(),
+                       +llvm::Value::MaximumAlignment);
+
+            llvm::AttrBuilder Attrs;
+            Attrs.addAlignmentAttr(Alignment);
+            AI->addAttr(llvm::AttributeSet::get(getLLVMContext(),
+                                                  AI->getArgNo() + 1, Attrs));
+          }
         }
 
         if (Arg->getType().isRestrictQualified())
           AI->addAttr(llvm::AttributeSet::get(getLLVMContext(),
                                               AI->getArgNo() + 1,
                                               llvm::Attribute::NoAlias));
 
         // Ensure the argument is the correct type.

lib/Sema/SemaDeclAttr.cpp

if (I->getAnnotation() == Str)
       return;
   }
   
   D->addAttr(::new (S.Context)
              AnnotateAttr(Attr.getRange(), S.Context, Str,
                           Attr.getAttributeSpellingListIndex()));
 }
 
+static void handleAlignValueAttr(Sema &S, Decl *D,
+                                 const AttributeList &Attr) {
+  S.AddAlignValueAttr(Attr.getRange(), D, Attr.getArgAsExpr(0),
+                      Attr.getAttributeSpellingListIndex());
+}
+
+void Sema::AddAlignValueAttr(SourceRange AttrRange, Decl *D, Expr *E,
+                             unsigned SpellingListIndex) {
+  AlignValueAttr TmpAttr(AttrRange, Context, E, SpellingListIndex);
+  SourceLocation AttrLoc = AttrRange.getBegin();
+
+  QualType T;
+  if (TypedefNameDecl *TD = dyn_cast<TypedefNameDecl>(D))
+    T = TD->getUnderlyingType();
+  else if (ValueDecl *VD = dyn_cast<ValueDecl>(D))
+    T = VD->getType();
+  else
+    llvm_unreachable("Unknown decl type for align_value");
+
+  if (!T->isDependentType() && !T->isAnyPointerType() &&
+      !T->isReferenceType() && !T->isMemberPointerType()) {
+    Diag(AttrLoc, diag::warn_attribute_pointer_or_reference_only)
+      << &TmpAttr /*TmpAttr.getName()*/ << T << D->getSourceRange();
+    return;
+  }
+
+  if (!E->isValueDependent()) {
+    llvm::APSInt Alignment(32);
+    ExprResult ICE
+      = VerifyIntegerConstantExpression(E, &Alignment,
+          diag::err_align_value_attribute_argument_not_int,
+            /*AllowFold*/ false);
+    if (ICE.isInvalid())
+      return;
+
+    if (!Alignment.isPowerOf2()) {
+      Diag(AttrLoc, diag::err_alignment_not_power_of_two)
+        << E->getSourceRange();
+      return;
+    }
+
+    D->addAttr(::new (Context)
+              AlignValueAttr(AttrRange, Context, ICE.get(),
+              SpellingListIndex));
+    return;
+  }
+
+  // Save dependent expressions in the AST to be instantiated.
+  D->addAttr(::new (Context) AlignValueAttr(TmpAttr));
+  return;
+}
+
 static void handleAlignedAttr(Sema &S, Decl *D, const AttributeList &Attr) {
   // check the attribute arguments.
   if (Attr.getNumArgs() > 1) {
     S.Diag(Attr.getLoc(), diag::err_attribute_wrong_number_arguments)
       << Attr.getName() << 1;
     return;
   }
 
case AttributeList::AT_IBOutletCollection:
     handleIBOutletCollection(S, D, Attr);
     break;
   case AttributeList::AT_Alias:
     handleAliasAttr(S, D, Attr);
     break;
   case AttributeList::AT_Aligned:
     handleAlignedAttr(S, D, Attr);
     break;
+  case AttributeList::AT_AlignValue:
+    handleAlignValueAttr(S, D, Attr);
+    break;
   case AttributeList::AT_AlwaysInline:
     handleAlwaysInlineAttr(S, D, Attr);
     break;
   case AttributeList::AT_AnalyzerNoReturn:
     handleAnalyzerNoReturnAttr(S, D, Attr);
     break;
   case AttributeList::AT_TLSModel:
     handleTLSModelAttr(S, D, Attr);

lib/Sema/SemaTemplateInstantiateDecl.cpp

if (Result.isInvalid())
       return;
     OE = Result.getAs<Expr>();
   }
 
   S.AddAssumeAlignedAttr(Aligned->getLocation(), New, E, OE,
                          Aligned->getSpellingListIndex());
 }
 
+static void instantiateDependentAlignValueAttr(
+    Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
+    const AlignValueAttr *Aligned, Decl *New) {
+  // The alignment expression is a constant expression.
+  EnterExpressionEvaluationContext Unevaluated(S, Sema::ConstantEvaluated);
+  ExprResult Result = S.SubstExpr(Aligned->getAlignment(), TemplateArgs);
+  if (!Result.isInvalid())
+    S.AddAlignValueAttr(Aligned->getLocation(), New, Result.getAs<Expr>(),
+                        Aligned->getSpellingListIndex());
+}
+
 static void instantiateDependentEnableIfAttr(
     Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
     const EnableIfAttr *A, const Decl *Tmpl, Decl *New) {
   Expr *Cond = nullptr;
   {
     EnterExpressionEvaluationContext Unevaluated(S, Sema::Unevaluated);
     ExprResult Result = S.SubstExpr(A->getCond(), TemplateArgs);
     if (Result.isInvalid())
for (const auto *TmplAttr : Tmpl->attrs()) {
     }
 
     const AssumeAlignedAttr *AssumeAligned = dyn_cast<AssumeAlignedAttr>(TmplAttr);
     if (AssumeAligned) {
       instantiateDependentAssumeAlignedAttr(*this, TemplateArgs, AssumeAligned, New);
       continue;
     }
 
+    const AlignValueAttr *AlignValue = dyn_cast<AlignValueAttr>(TmplAttr);
+    if (AlignValue) {
+      instantiateDependentAlignValueAttr(*this, TemplateArgs, AlignValue, New);
+      continue;
+    }
+
     const EnableIfAttr *EnableIf = dyn_cast<EnableIfAttr>(TmplAttr);
     if (EnableIf && EnableIf->getCond()->isValueDependent()) {
       instantiateDependentEnableIfAttr(*this, TemplateArgs, EnableIf, Tmpl,
                                        New);
       continue;
     }
 
     // Existing DLL attribute on the instantiation takes precedence.

test/CodeGen/align_value.cpp

+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+
+typedef double * __attribute__((align_value(64))) aligned_double;
+
+void foo(aligned_double x, double * y __attribute__((align_value(32))),
+         double & z __attribute__((align_value(128)))) { };
+// CHECK: define void @_Z3fooPdS_Rd(double* align 64 %x, double* align 32 %y, double* dereferenceable(8) align 128 %z)
+

test/Sema/align_value.c

+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+typedef double * __attribute__((align_value(64))) aligned_double;
+
+void foo(aligned_double x, double * y __attribute__((align_value(32)))) { };
+
+// expected-error@+1 {{requested alignment is not a power of 2}}
+typedef double * __attribute__((align_value(63))) aligned_double1;
+
+// expected-error@+1 {{requested alignment is not a power of 2}}
+typedef double * __attribute__((align_value(-2))) aligned_double2;
+
+// expected-error@+1 {{attribute takes one argument}}
+typedef double * __attribute__((align_value(63, 4))) aligned_double3;
+
+// expected-error@+1 {{attribute takes one argument}}
+typedef double * __attribute__((align_value())) aligned_double3a;
+
+// expected-error@+1 {{attribute takes one argument}}
+typedef double * __attribute__((align_value)) aligned_double3b;
+
+// expected-error@+1 {{'align_value' attribute requires integer constant}}
+typedef double * __attribute__((align_value(4.5))) aligned_double4;
+
+// expected-warning@+1 {{'align_value' attribute only applies to a pointer or reference ('int' is invalid)}}
+typedef int __attribute__((align_value(32))) aligned_int;
+
+typedef double * __attribute__((align_value(32*2))) aligned_double5;
+
+// expected-warning@+1 {{'align_value' attribute only applies to variables and typedefs}}
+void foo() __attribute__((align_value(32)));
+

test/SemaCXX/align_value.cpp

+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+typedef double * __attribute__((align_value(64))) aligned_double;
+
+void foo(aligned_double x, double * y __attribute__((align_value(32))),
+         double & z __attribute__((align_value(128)))) { };
+
+template <typename T, int Q>
+struct x {
+  typedef T* aligned_int __attribute__((align_value(32+8*Q)));
+  aligned_int V;
+
+  void foo(aligned_int a, T &b __attribute__((align_value(sizeof(T)*4))));
+};
+
+x<float, 4> y;
+
+template <typename T, int Q>
+struct nope {
+  // expected-error@+1 {{requested alignment is not a power of 2}}
+  void foo(T &b __attribute__((align_value(sizeof(T)+1))));
+};
+
+// expected-note@+1 {{in instantiation of template class 'nope<long double, 4>' requested here}}
+nope<long double, 4> y2;
+