[PATCH] D54966: Implement P1007R3 `std::assume_aligned`

Hal Finkel via Phabricator reviews at reviews.llvm.org
Mon Dec 3 17:31:52 PST 2018

hfinkel added a comment.

In D54966#1317428 <https://reviews.llvm.org/D54966#1317428>, @rsmith wrote:

> In D54966#1314038 <https://reviews.llvm.org/D54966#1314038>, @EricWF wrote:
> > We don't need to use `__builtin_assume_aligned` to implement this.  We can use `__attribute__((assume_aligned(N)))` instead. That solves our constexpr problem.
> ...
> @chandlerc, @hfinkel: does an attribute-only implementation (with no constant evaluation enforcement) materially hurt the ability for the optimizer to use this annotation? Eg, in:
>   extern char k[16];
>   void f() {
>     // the initializer of p is a constant expression and might get constant-folded to &k by the frontend
>     char *p = std::assume_aligned<16>(&k);
>     // ...do stuff...
>   }
> the alignment assumption may well never be emitted as IR. Is that acceptable?

`__attribute__((assume_aligned(N)))` and `__builtin_assume_aligned` are, at the IR level, implemented in a very-similar way. For functions with that attribute on the return type, we essentially emit an alignment assumption on the return value at every call site (in CodeGenFunction::EmitCall). Thus, from the optimizer's perspective, I don't think that it makes a big difference.



More information about the libcxx-commits mailing list