With increasing multi-arch support in the userland and optimized implementations for these architectures we are getting a lot of functions whose contents look something like:

double performance_critical_function()
{
#if ARCH(x86_64)
    // fast x86 implementation
    asm volatile(...);
#elif ARCH(AARCH64)
    // fast ARM implementation
    asm volatile(...);
#if ARCH(RISCV64)
    // fast RISC-V implementation
    asm volatile(...);
#else
#    error "Unknown architecture"
#endif
}

This is increasingly unreadable and impractical. A developer working on these optimized implementations will usually focus on one architecture.

The idea is to split the implementation files into one implementation per architecture, like we already do in many places in the Kernel, and control which implementation to use in the build system or via conditional includes (in case of headers). A common implementation file still makes sense in many cases for functions that are always implemented in arch-independent C++.

CC @ADKaster.

Known offenders:

• LibC/fenv.cpp #22888
• LibC/math.cpp
• AK/Math.h
• CrashReporter/main.cpp (does the register printing belong here, anyways?)
• Debugger/main.cpp
• HackStudio/Debugger/RegisterModel.cpp
• functrace.cpp
• strace.cpp

Future candidates to look out for, if one decides to expand them with more arch-specific implementations:

• AK/SIMDMath.h
• AK/Memory.h
• LibC/string.cpp
• Several places in LibDebug