[clang] [clang] Add __builtin_start_object_lifetime builtin. (PR #82776)

Sam McCall via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 27 11:38:54 PDT 2024


sam-mccall wrote:

This has been dormant in part while thinking about the memcpy half, I think.
Something like https://github.com/llvm/llvm-project/pull/86512 solves that well but likely needs this change too.

> I am a bit concerned that this does not actually have the desired semantics at all, but @zygoloid seemed to be "happy" with it. I will admit I struggle understanding the motivation of adding a builtin that does...less than it should.

This does something both useful and correct with `-fno-strict-aliasing`. I think we're far from alone in building in this mode (in part precisely because of existing TBAA soundness questions!)[1].

I think it gets us incrementally closer to fully supporting std::start_lifetime_as: if there are specific miscompiles this would produce with strict-aliasing enabled, we can now observe them and use them to validate e.g. the `llvm.tbaa.fence` proposal. (It looks like what we need here but I also don't understand the LLVM change deeply).

> Similarly, do you have plans for the array version of start_lifetime_as?

I think we need a similar parallel version of this, e.g.: `__start_dynamic_array_lifetime(T*, size_t) -> T*`.
This seems like a purely mechanical extension that could be done in this patch or subsequently. Preferences?

[1] I hope this is the year we can put some work into strict-aliasing and turn it on. By coincidence, our best estimate of the overall performance win is roughly the same as applying this optimization to one widely-used library...

https://github.com/llvm/llvm-project/pull/82776


More information about the cfe-commits mailing list