[libc-commits] [libc] [libc][docs] codify Policy on Assembler Sources (PR #88185)

[via libc-commits]

================
@@ -186,3 +186,32 @@ We expect contributions to be free of warnings from the `minimum supported
 compiler versions`__ (and newer).
 
 .. __: https://libc.llvm.org/compiler_support.html#minimum-supported-versions
+
+Policy on Assembler sources
+===========================
+
+Coding in high level languages such as C++ provides benefits relative to low
+level languages like Assembler, such as:
+
+* Improved safety
+* Instrumentation
+
+  * Code coverage
+  * Profile collection
+* Sanitization
+* Debug info
+
+While its not impossible to have Assembler code that correctly provides all of
+the above, we do not wish to maintain such Assembler sources in llvm-libc.
+
+That said, there a few functions provided by llvm-libc that are more difficult
+to implement or maintain in C++ than Assembler. We do use inline or out-of-line
+Assembler in an intentionally minimal set of places; typically places where the
+stack or individual register state must be manipulated very carefully for
+correctness.
+
+Contributions adding Assembler for performance are not welcome. Contributors
----------------
enh-google wrote:

aye, but google3 is a bit of a monoculture... i meant something more like Android, where every SoC vendor will want workarounds for their SoC's (and SoCs') specific characteristics. commercial in the sense of "where people sell products based on benchmark scores", for better and -- mostly -- worse.

https://github.com/llvm/llvm-project/pull/88185