[libc][docs] codify Policy on Assembler Sources by nickdesaulniers · Pull Request #88185 · llvm/llvm-project (original) (raw)

Most of the time the semantics are accessible through compiler builtins (e.g. prefetch instructions) but there are situations where its impossible to access a specific CPU instruction from C++ (e.g. rep movsb, dc zva).

In principle, I agree with @dpxf that we should change the compiler and make sure we have a way to reach out to special semantics from the frontend (e.g. introduction of __builtin_memcpy_inline) but in practice, the fact that we have to support old versions of both Clang and GCC makes it much harder. For instance, inline_memcpy has a special path for Clang and a fallback for GCC. I'm not digging into the details here but this can lead to suboptimal codegen for GCC when generating memcpy, it also requires that the GCC version is compiled with -fno-builtin-memcpy, where the Clang version doesn't. So, if -in principle- we should improve the compiler, the effort to get both Clang and GCC inline on these intrinsics is substantial, notwithstanding the compiler release cycles, fallback code and build systems flags we'll have to maintain to support older versions.

So practically, for these admittedly rare cases, I think inline asm strikes a good balance between portability, maintenance and functionality. The layered approach from #88185 (comment) makes perfect sense to me. How about also requiring that such PRs containing asm statements should always be reviewed by at least two project maintainers?