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

yeah, that's easier for Android where we explicitly only support one version of one compiler at any given time.

in my experience though you're unlikely to have people _actually_ take you up on this. certainly not the same people who'll want to give you -- naming no names -- "a binary blob in ASCII form, containing the output of our proprietary compiler on source that may or may not be the same as your source", who are the usual people _i_ have to tell to go away and improve llvm instead :-) (this is typically for libm stuff.)

the libc stuff is always the string/memory routines, and there it's going to be stuff like https://github.com/ARM-software/optimized-routines/issues/68 that you're not going to want anyway. luckily it's been quite quiet for us for a decade, as arm64 was effectively single-source, arm32 was dead, and x86/x86-64 weren't commercially significant (though we do have all the usual `s*e*[2-4]` and `avx\d+` variants anyway). personally i'd be very interested to see how many of those you can make go away with function multiversioning. (but probably never the non-temporal stuff, and convincing people who're paid to make benchmarks go up that making benchmarks go up is useless, well, "It is difficult to get a man to understand something when his salary depends upon his not understanding it".)

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