Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I haven't looked at the patch closely. But I wonder whether we really want this.
For example a user uses the unstable ABI and uses std::unique_ptr in an interface of their own library.
When this library is used with other libraries that use different language versions, for example C++17 and C++20, the layout of std::unique_ptr may differ between these two libraries, causing ODR violations.
(Obviously this affects more types since __compressed_pair is used at a lot of places.
Unless somebody convinces me I'm mistaken regarding the ODR violations, I would suggest to abandon this patch.
(In that case let's discuss it further on Discord.)
We've discussed it on Discord and it looks like it might be save. Once it's certain the reasoning why it's safe should be part of the summary so it becomes part of the commit message.
libcxx/include/__memory/compressed_pair.h | ||
---|---|---|
164 | I would like to better understand the benefit of making this change. What do we gain? At a glance, we seem to gain EBO for types marked final -- I think that's it, right? I wonder whether it's worth adding complexity for that, but I'm not closed to the idea. | |
libcxx/include/__memory/shared_ptr.h | ||
333 | I don't think this part of the patch should be tied to the change in __compressed_pair. It's really not related -- the idea is only that if we're using the unstable ABI, we can suddenly simplify the implementation of the control block, but doing so has nothing to do with using [[no_unqiue_address]] inside __compressed_pair. |
libcxx/include/__memory/compressed_pair.h | ||
---|---|---|
164 | There are a few things: | |
libcxx/include/__memory/shared_ptr.h | ||
333 | It kind-of has. The control-block is tied to the layout of the ABIv1 __compressed_pair. So the ABIv2 control block has to be used when enabling the ABIv2 __compressed_pair. Do you just want to have another macro or should I put in an error if _LIBCPP_ABI_COMPRESSED_PAIR_USE_NO_UNIQUE_ADDRESS is set but something like _LIBCPP_ABI_SHARED_PTR_SIMPLE_CONTROL_BLOCK is not set? I don't think there are any other _LIBCPP_ABI* macros that depend on another yet. |
I would like us to check whether https://reviews.llvm.org/D63744#2369890 can be implemented (especially since we now support recent compilers only, which wasn't the case back then). If that works, I think this would remove the need for this patch and provide a bunch of additional benefits even in the stable ABI. If not, then I think this patch is fine. Requesting changes for now.
libcxx/include/__memory/shared_ptr.h | ||
---|---|---|
333 | Ahh, I see it now -- there is no __get_second_base function after your patch, so the control block implementation does need to change. |
I would like to better understand the benefit of making this change. What do we gain? At a glance, we seem to gain EBO for types marked final -- I think that's it, right?
I wonder whether it's worth adding complexity for that, but I'm not closed to the idea.