llvm / llvm/llvm-project

Document current status of preserve_most/all/none cc

Open
#178,277 1 comment 0 reactions 0 assignees View on GitHub
documentation
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.