Document current status of preserve_most/all/none cc
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
Documentation for `preserve_most` states that the feature is experimental and slated for use in Objective-C, but that note was added in 2016 (https://github.com/llvm/llvm-project/commit/35aa5cecf25162f4a88cdf1dbfe3f8fc3ed1a91c).
> This calling convention will be used by a future version of the Objective-C runtime and should therefore still be considered experimental at this time. Although this convention was created to optimize certain runtime calls to the Objective-C runtime, it is not limited to this runtime and might be used by other runtimes in the future too. The current implementation only supports X86-64, but the intention is to support more architectures in the future.
There are a few other places aspects in which documentation should be updated to reflect 2026, including:
* Updating the docs to reflect the current intended usage in Objective-C.
* Re-evaluating the current “experimental” status of `preserve_most` to ensure it’s up to date. I’m unsure when a feature in clang qualifies for promotion out of experimental. It’s been around since 2016, though it does have relatively recent bug fixes. I did some basic searching, and FWIW it’s used in the linux kernel for cold validation functions [1], some parts of v8 for error handling [2], tcmalloc for an initializer [3], and in Protobuf' μpb [4].
* Documenting the intended behavior for flags registers -- https://github.com/llvm/llvm-project/issues/64490.
* Addressing https://github.com/llvm/llvm-project/issues/105588 to some degree. I’ve sent a patch for glibc's PLT resolution [5], but it’s still pending viability. If it can't/won't be fixed in popular dynamic linkers, then we should at least note this pitfall in the documentation or provide warnings etc, as it seems like many folks rediscover this footgun. @fweimer-rh has good example documentation warning about PLT interactions in https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/45.
Hi @swiftix, @ributzka, I see you were the original authors of the `preserve_most` docs (though now ~10y ago). I'm not seeing references in https://github.com/apple-oss-distributions/objc4. Do you know whether Objective-C runtime relies or intends to rely on `preserve_most`? Or could you help me find the right people? Thanks!
[1] https://github.com/torvalds/linux/commit/aebc7b0d8d91bbc69e976909963046bc48bca4fd
[2] https://github.com/v8/v8/blob/4d1e2794e00a1071e774361994ac5ac4b6d3f147/include/v8config.h#L394
[3] https://github.com/google/tcmalloc/blob/b4600aef594ece086808c6d7d9e720bdd51a4188/tcmalloc/static_vars.h#L214
[4] https://github.com/protocolbuffers/protobuf/blob/74a5ee1852602ab2bf7bf78cdb11185f564209e7/upb/wire/decode_fast/cardinality.h#L523
[5] https://patchwork.sourceware.org/project/glibc/patch/20251212003913.12229-2-jtstogel@gmail.com
Contributor guide
Research direction
Start with the existing preserve_most documentation and compare its Objective-C, experimental-status, flags-register, and dynamic-linker notes against the linked LLVM, objc4, ABI, and external usage references. Done means agreeing on the current intended behavior and status, then updating or adding documentation for the issues and PLT pitfall identified here.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- objective-c
- Domain
- compilers, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100