[PATCH] D114732: [clang] Mark `trivial_abi` types as "trivially relocatable".

Devin Jeanpierre via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 18 16:55:48 PST 2022


devin.jeanpierre added a comment.

OK, while I'm struggling to set up a new Windows machine so I can make sure this works on Windows...  @Quuxplusone, after this is merged, do you want to rebase D67524 <https://reviews.llvm.org/D67524> on top of this, or should I? I can review it -- I think when I looked at it, I only had two ideas for changes:

1. May need to guard all of these optimizations on the allocator being the standard allocator, since otherwise the change in the number of constructor/destructor calls would be observable to more than just the annotated type.

2. changing `std::swap` to correctly handle potentially-overlapping-objects. My thought is we could test that there's no reusable tail padding.

First draft: `has_unique_object_representations` is conservative -- on the Itanium ABI, "POD for the purposes of layout" types can have padding which isn't reused when it's a potentially overlapping subobject.

Second draft: check by hand:

      
  struct TestStruct {
    [[no_unique_address]] T x;
    // not sure if this needs to be a bitfield or anything like that, but the idea is this.
    char extra_byte;
  };
  bool has_padding = sizeof(TestStruct) == sizeof(T);
      

Third draft: we can improve on this further still by iterating over different numbers of characters to determine the exact size of the padding, and memcpy only the non-padding parts.

---

(D63620 <https://reviews.llvm.org/D63620> could in some form also be ported over, but it needs to be guarded behind ABI stability, since `[[clang::trivial_abi]]` is an ABI breaking change. For example, the same way it was done for unique_ptr <https://libcxx.llvm.org//DesignDocs/UniquePtrTrivialAbi.html>, with the same benefits.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114732



More information about the cfe-commits mailing list