[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:

you're not carving out an exception for the string/memory functions? or just punting that down the road until commercial users show up?

explicitly mention that anyone wanting to go that route should consider whether they can do it via a builtin? (like all the math functions that turn into a single instruction on modern architectures, or stuff like ffs() or abs() etc?)

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