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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
