maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/align_value.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

33 lines
1.3 KiB
C
Raw Normal View History

Initial support for the align_value attribute This adds 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 attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, 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. llvm-svn: 218910
2014-10-03 05:21:25 +08:00
// 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)));