Clang编译ARMv8代码时Machine Code Sinking与Virtual Register Rewriter步骤耗时过长的优化求助

• ARMv8 Register Architecture Complexity: ARMv8 has far more general-purpose registers (31 vs ARMv7's 13) plus advanced SIMD/register features. The Virtual Register Rewriter has to handle a much larger mapping space between virtual and physical registers, and this overhead scales non-linearly with the number of virtual registers—especially problematic for huge auto-generated functions.
• Auto-Generated Code Pathologies: If your function is monolithic (thousands of lines, hundreds of basic blocks) or has dense, intertwined memory operations, Machine Code Sinking will spend exponentially more time analyzing data dependencies to move instructions to optimal positions. ARMv8's stricter memory ordering rules also add extra work compared to ARMv7.
• Default Optimization Aggressiveness: Clang and GCC enable more aggressive optimizations for ARMv8 by default (e.g., deeper dependency analysis, better SIMD utilization) that aren't feasible on ARMv7. These directly amplify the workload for both the sinking and register rewriting passes.
• Cross-Architecture Tuning Gaps: x86_64's register renaming and instruction scheduling model is drastically different, and Clang's optimizers are heavily tuned for this architecture. Similar functions will process faster on x86_64 even if they're large, purely due to better optimizer alignment.

Since refactoring space is limited, try these targeted tweaks:

• Split Monolithic Functions: If your code generator supports it, split the huge function into smaller, logically separated sub-functions. Smaller functions drastically shrink the scope of analysis for both passes—even splitting into 2-3 parts can cut optimization time by 50% or more.
• Disable Specific Optimizations for the Problem File:
  • For Machine Code Sinking: Use clang -mllvm -disable-machine-sink to turn off this pass for the problematic file. Test if the resulting code performance is acceptable—auto-generated code often has redundant computations where sinking provides minimal gains.
  • For Virtual Register Overhead: Lower the optimization level for just this file (e.g., -O2 instead of -O3) to reduce the number of virtual registers created in earlier passes, lightening the rewriter's workload.
• Tweak Code Generator Output: If you have any control over the generator, ask it to:
  • Reuse registers instead of spawning new ones for trivial operations
  • Minimize nested memory accesses in tight loops (these force the sinking pass to do extra dependency checks)

Speedscope is useful, but these tools can uncover deeper bottlenecks:

• Clang -ftime-report: A lighter alternative to -ftime-trace that gives a concise summary of time spent in each pass. It will confirm if the two passes are the dominant bottlenecks, and break down sub-step costs (e.g., dependency analysis vs instruction movement in sinking).
• perf: Run perf record -g -- clang [your-compile-flags] to sample the compiler's execution. This shows exactly which CPU functions are eating up time—for example, if the register rewriter is stuck in a loop processing register conflicts, perf will highlight that.
• Clang -Rpass Flags: Use -Rpass=machine-sink to see which instructions are being sunk, and -Rpass-analysis=machine-sink to get details on why the pass is fixated on certain code regions. This can help spot pathological patterns in the auto-generated code.
• System Resource Monitoring: Use htop or vmstat during compilation to check if you're hitting memory limits (swap usage will destroy performance). If the compiler is swapping to disk, adding more RAM could drastically cut optimization time.

To get more targeted advice, share:

• Exact file/function metrics: Number of lines, basic blocks, and approximate virtual register count (use Clang's -print-after-all flag, filtered to the problematic function)
• Auto-generated code type: Is it DSP/ML computations, matrix operations, or something else? Does it have extremely large loops or dense conditional branches?
• Compiler versions: Exact Clang and GCC versions (e.g., Clang 14 vs Clang 17—newer versions often have optimizer performance fixes)
• Full compilation flags: Include flags like -O3, -flto, or -march=armv8-a+crypto that might be amplifying overhead
• System specs: CPU model (e.g., Cortex-A78), RAM size, and whether you're cross-compiling or compiling on the target

内容的提问来源于stack exchange，提问作者Matt