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

Richard Smith - zygoloid via Phabricator reviews at reviews.llvm.org
Tue Dec 4 15:21:03 PST 2018


rsmith added a comment.

In D54966#1317750 <https://reviews.llvm.org/D54966#1317750>, @hfinkel wrote:

> In D54966#1317428 <https://reviews.llvm.org/D54966#1317428>, @rsmith wrote:
>
> > @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.


The point here is that you may well get //no IR annotation whatsoever// for the above call, because the frontend might constant-evaluate the initializer of `p` down to just `&k`, and then emit IR that just initializes `p` to `&k` with no alignment assumption. Whereas if we treated `assume_aligned<N>(p)` as non-constant in the cases where we cannot prove that `p` is suitably aligned (as `__builtin_assume_aligned` does), then we would emit IR for the alignment assumption, but the downside is that the initializer of `p` would no longer be a constant expression.

Essentially, what I'm trying to gauge here is, is it OK that you probably don't actually get an alignment assumption in a function like the `f()` above, because it will probably be constant-evaluated away to nothing? Or do we need the constant evaluator to have some kind of side-channel by which it can communicate back to the code generator that an alignment assumption should be applied to `k`? Or, indeed, should `assume_aligned<N>(p)` not be treated as a constant expression unless we can prove during constant expression evaluation that `p` is in fact suitably aligned -- as GCC and Clang currently do for `__builtin_assume_aligned`?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54966/new/

https://reviews.llvm.org/D54966





More information about the libcxx-commits mailing list