gccrs: Use BIR drop analysis in backend cleanup
gccrs uses BIR drop analysis to optimize backend cleanup by skipping drops for moved locals.
gccrs now integrates its Basic Intermediate Representation (BIR) drop analysis into the backend cleanup phase. This optimization allows the compiler to skip generating cleanup code for Drop operations on locals that have been moved, as they are no longer valid. Unaffected locals continue to use existing cleanup logic.
In Details
The gccrs backend cleanup has been connected to the BIR-based drop analysis. Specifically, CompileDrop::build_current_scope_drop_cleanup now consults DropAnalysis::is_definitely_dead to avoid generating unnecessary Drop glue for values that have been moved out. This leverages the static analysis of dead code within the BIR to improve the generated backend code efficiency. Static and unclassified Drops retain their previous behavior.
- BIR
- Basic Intermediate Representation. An intermediate representation used by gccrs during compilation, likely a form of Static Single Assignment (SSA) or similar, used for analysis and optimization before generating lower-level code.
- drop analysis
- Analysis performed by the compiler to determine when a value's destructor (or
Dropimplementation in Rust) needs to be called. This helps in optimizing memory management and avoiding unnecessary deallocations. - backend cleanup
- The phase in the compiler's backend where resources are finalized, temporary variables are managed, and code is optimized for the target architecture. In Rust, this includes managing memory and ensuring proper deallocation.
- moved locals
- In Rust, when a value is moved, ownership is transferred to another variable. The original variable can no longer be used. For drop analysis, this means the
Dropimplementation for the moved value does not need to be called on the original variable's scope.