Unreachable code

The existence of an unreachable code may be due to various factors, for example:

• Software errors in complex conditional transitions ;
• Due to internal transformations performed by the optimizing compiler ;
• Incomplete testing of a new or modified program that failed to detect unreachable code;
• When correcting one error, the programmer created another error, which bypasses unreachable code and was not detected during testing;
• Outdated code that was not completely removed by the programmer because it was mixed with existing code;
• Outdated code that the programmer forgot to delete;
• Previously useful code that will never be executed, since, in the future, data entry will never lead to the execution of this code;
• Outdated code that was intentionally saved but made unreachable so that it can be included in the program again if necessary;
• Debug constructs and residual parts of the code that still need to be removed from the program.

In the last five cases, the unreachable code is inherited, that is, code that was once useful, but not used now.

Consider the following C example:

  int foo ( int x , int y )
  {
    return x + y ;
    int z = x * y ;  / * Inaccessible code * /
  }

The operation int z = x*y is an unreachable code, since it exits the procedure (the operations that stand after returning from the procedure may not be the unreachable code, for example, if the goto statement refers to the label after the return).

The search for unreachable code in the source code can be performed using static code analysis ^{[3] [4]} . In the optimizing compiler , identifying and removing unreachable code can optimize the removal of unreachable code , which finds unreachable nodes in the control flow graph and deletes them ^[6] . A simple analysis of a CFG graph for unreachable nodes is often implemented in the compiler as a separate function, i.e. garbage collector , which is called immediately after the transformations that can change the graph of the control flow ^[7] .

The code may become unreachable as a result of performing other compiler transformations on the , for example, optimizing the removal of common subexpressions .

In practice, the complexity of the analysis implemented significantly affects the amount of unreachable code to be detected. For example, after folding constants and a simple analysis of the control flow, you may find that the code inside the if in the following example is unreachable:

  int foo ( void )
  {
    int n = 2 + 1 ;
    if ( n > 4 )
    {
      printf ( "% d" , n );  / * Inaccessible code * /
    }
  }

However, in order to identify unreachable code in the following example, it is necessary to apply a much more complex analysis algorithm:

  int foo ( void )
  {
    double x = sqrt ( 2 );
    if ( x > 4 )
    {
      printf ( "% lf" , x );  / * Inaccessible code * /
    }
  }

One practical solution is an approach that first performs a simple analysis of identifying unreachable code, and then uses a profiler to handle more complex cases. The profiler cannot prove that any part of the code is unreachable, but it can be a good heuristic for finding suspicious nodes that are probably unreachable. After finding these potentially unreachable nodes, you can apply some sort of powerful algorithm for analyzing unreachable code.

• Dead code
• Dead Code Removal
• Removing Unreachable Code

• Cooper and Torczon. Engineering a Compiler. - Morgan Kaufmann, 2011 .-- S. 544-550, 593. - ISBN 978-0-12-088478-0 .
• Alfred Aho, Monica Lam, Ravi Seti, Jeffrey Ullman. Compilers: principles, technologies and tools = Compilers: Principles, Techniques, and Tools. - 2nd edition. - M .: "Williams", 2008. - 1184 p. - 1,500 copies - ISBN 978-5-8459-1349-4 .
• Muchnick, Steven S. Advanced Compiler Design and Implementation. - Morgan Kaufmann Publishers , 1997 .-- S. 580-582. - ISBN 1-55860-320-4 .