Code Sinking: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
'''Code sinking''', sometimes referred to as '''lazy code motion''', is a compiler optimization that moves computations into less frequently executed regions of code. If an operation is executed before a branch and only one branch uses its result, code sinking delays the computation and places it inside the branch so the operation is executed only on the path where it is needed.<ref>[https://en.wikipedia.org/wiki/Code_motion Wikipedia – Code Motion]</ref>
'''Code sinking''', sometimes referred to as '''lazy code motion''', is a compiler optimization that moves computations into less frequently executed regions of code. If an operation is executed before a branch and only one branch uses its result, code sinking delays the computation and places it inside the branch so the operation is executed only on the path where it is needed.<ref>[https://en.wikipedia.org/wiki/Code_motion Wikipedia – Code Motion]</ref> By executing computations only when their results are required, code sinking can reduce the instruction's execution count, lower register pressure, and sometimes decrease code size. Unlike [[Dead Code Elimination|dead code elimination]], which removes instructions only if their results are never used, code sinking removes or moves instructions even when there is a possible use on some execution path, as long as redundant executions are avoided.<ref>[https://en.wikipedia.org/wiki/Code_motion Wikipedia – Code Motion]</ref> Modern compilers implement sinking as part of their code-motion passes; for example, LLVM’s <code>sink</code> pass moves instructions into successor blocks so they aren’t executed on paths where their results aren’t needed.<ref>[https://llvm.org/docs/Passes.html#sink-code-sinking LLVM Pass Documentation – Sink]</ref>
The technique also applies to loops: when a value changes on every iteration, moving the computation from outside a loop into the loop body reduces redundant work and ensures the result is produced exactly when needed.<ref>[https://www.geeksforgeeks.org/compiler-design/global-code-scheduling-in-compiler-design/ GeeksforGeeks – Global Code Scheduling]</ref> 
By executing computations only when their results are required, code sinking can reduce the instruction count, lower register pressure, and sometimes decrease code size. Unlike dead code elimination, which removes instructions only if their results are never used, code sinking removes or moves instructions even when there is a possible use on some execution path, as long as redundant executions are avoided.<ref>[https://en.wikipedia.org/wiki/Code_motion Wikipedia – Code Motion]</ref>
Modern compilers implement sinking as part of their code-motion passes; for example, LLVM’s `sink` pass moves instructions into successor blocks so they aren’t executed on paths where their results aren’t needed.<ref>[https://llvm.org/docs/Passes.html#sink-code-sinking LLVM Pass Documentation – Sink]</ref>


== Code Sinking Transformation in emmtrix Studio ==
== Code Sinking Transformation in emmtrix Studio ==
In '''emmtrix Studio''', the Code Sinking Transformation can be applied using a `#pragma` directive or via the graphical user interface. The transformation analyzes control flow and data dependencies to relocate computations to later points in the code (e.g., into conditional branches or deeper inside loops), while preserving program semantics. Expressions whose results are used only in specific branches are moved into those branches, reducing the workload on frequently executed paths.
In '''emmtrix Studio''', the Code Sinking Transformation can be applied using a <code>#pragma</code> directive or via the graphical user interface. The transformation analyzes control flow and data dependencies to relocate computations to later points in the code (e.g., into conditional branches or deeper inside loops), while preserving program semantics. Expressions whose results are used only in specific branches are moved into those branches, reducing the workload on frequently executed paths.


=== Typical Usage and Benefits ===
=== Typical Usage and Benefits ===
Line 14: Line 11:


== Example ==
== Example ==
The following example shows how expressions `x` and `y` are originally computed unconditionally, even though only one of them is used depending on the condition. After code sinking, each computation is moved into its corresponding branch.
The following example shows how expressions <code>x</code> and <code>y</code> are originally computed unconditionally, even though only one of them is used depending on the condition. After code sinking, each computation is moved into its corresponding branch.


{| class="wikitable"
{| class="wikitable"
Line 20: Line 17:
! Before Transformation !! After Transformation
! Before Transformation !! After Transformation
|-
|-
| <syntaxhighlight lang="c">
|Original code: both x and y are computed on every iteration.<syntaxhighlight lang="c">
// Original code: both x and y are computed on every iteration.
#include <stdio.h>
#include <stdio.h>


Line 40: Line 36:
}
}
</syntaxhighlight>
</syntaxhighlight>
| <syntaxhighlight lang="c">
|After code sinking: the computations are moved into the appropriate branch.<syntaxhighlight lang="c">
// After code sinking: the computations are moved into the appropriate branch.
#include <stdio.h>
#include <stdio.h>


Line 68: Line 63:
|-
|-
| <code>conditional</code> || false || Adds additional <code>if</code> blocks when needed to enable legal code movement.
| <code>conditional</code> || false || Adds additional <code>if</code> blocks when needed to enable legal code movement.
|-
| <code>expected_moved_exprs</code> || −1 || Used for test validation. If set ≥ 0, the transformation will verify the number of moved expressions.
|}
|}


Bots, Bureaucrats, Interface administrators, smwadministrator, smwcurator, smweditor, Administrators
2,502

edits

Cookies help us deliver our services. By using our services, you agree to our use of cookies.

Navigation menu