[llvm-dev] Placement new and TBAA

[Hubert Tong via llvm-dev]

On Thu, Dec 1, 2016 at 11:24 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

> What kind of intrinsic are you thinking about here?
>
I propose two intrinsics: llvm.lifetime.reuse and
llvm.tbaa.pointer_identity.barrier.
Both intrinsics take at least one argument: an address value to the
affected memory.
llvm.lifetime.reuse takes one other argument: the minimum size of the
affected memory.
Both intrinsics return an address value: some version of the value passed
in.

For llvm.tbaa.pointer_identity.barrier, the semantics are that the return
address value is distinct from the argument in such a way that it achieves
the necessary effect of std::launder with regards to TBAA.
Calls to llvm.tbaa.pointer_identity.barrier shall not be reordered with
respect to each other (and thus, also functions which may perform such a
call to llvm.tbaa.pointer_identity.barrier).
Note: it may be the case that, at this time,
llvm.tbaa.pointer_identity.barrier only maintains an ordering between uses
of its return value and the intrinsic itself.
Note: it may be possible to relax the reordering restriction based on the
storage reachable from the argument pointer.

For llvm.lifetime.reuse(p, sz) (placement new):
Acts as llvm.tbaa.pointer_identity.barrier(p), except that the reachable
storage contains at least [p, p + sz), with additional semantics as follows.

Conceptually, this kind of acts as (but is more prohibitive than) a store
of undef over at least sz bytes over the memory starting at p
(unfortunately, no TBAA information as to what it writes over is obvious
from the immediate context at the source level).

Assuming that the loads and stores discussed below are ones which may
access the affected memory:
This should mean that all loads observing previous stores should not,
relative to the intrinsic, move to occur later.
(All stores observed by said loads should occur before said load).

If an invented load of the affected memory immediately before the intrinsic
may observe a store, said store should should not, relative to the
intrinsic, move to occur later;
however, if the invented load is the only observation of said store, the
store should be removed as dead.

Thus, all accesses to a defined value of the old object must occur before
the llvm.lifetime.reuse intrinsic (even if it is the intrinsic that it
being moved).

By the language, either the old object type and the new object type already
alias, or all accesses to the new object must either use the return value
from llvm.lifetime.reuse, or the return value of a later
llvm.tbaa.pointer_identity_barrier.
Thus, llvm.lifetime.reuse acts to separate accesses of the old object from
accesses of the new object.


>
> --
> Mehdi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161201/e59cc161/attachment.html>