Skip to content

LLVM does not need to trash caller-saved registers.

  • *Summary**: This ticket is a simplification of the LLVM backend that I already plan to do in another branch, but I'd like to push the patch into master, and then merge from master into that branch.

The LLVM backend attempts to trash the physical registers corresponding to Rx, Fx, and Dx registers that are caller-saved before an FFI call by emitting a sequence such as this:

  store i64 undef, i64* %R3_Var
  store i64 undef, i64* %R4_Var
  store i64 undef, i64* %R5_Var
  store i64 undef, i64* %R6_Var
  store float undef, float* %F1_Var
  store double undef, double* %D1_Var
  store float undef, float* %F2_Var
  store double undef, double* %D2_Var
  store float undef, float* %F3_Var
  store double undef, double* %D3_Var
  store float undef, float* %F4_Var
  store double undef, double* %D4_Var
  store float undef, float* %F5_Var
  store double undef, double* %D5_Var
  store float undef, float* %F6_Var
  store double undef, double* %D6_Var
  %ln7bu = call ccc double (double) @llvm.sin.f64( double %ln7bs ) nounwind

Where the Rx/Fx/Dx registers are chosen based on what physical register those global registers map to, and whether those physical registers are caller-saved according to the C ABI.

I'm certain this is unnecessary, as there is no way to know the physical register corresponding to those vars within an LLVM IR function. The calling convention used for the FFI call will preserve caller-saved registers as needed, i.e., only if such a value is needed after the call.

Trac metadata
Trac field Value
Version 8.0.1
Type Bug
TypeOfFailure CompileTimePerformance
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related #4992 (closed)
Blocking
CC
Operating system
Architecture
Edited by Kavon Farvardin
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information