This commit is contained in:
Matthias Veigel
parent
236a1ddf6b
commit
e6a7f67825
GPG Key ID:
2437494E09F13876
155
cc-by.svg
155
cc-by.svg
@ -1,155 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://web.resource.org/cc/"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="120"
|
||||
height="42"
|
||||
id="svg2759"
|
||||
sodipodi:version="0.32"
|
||||
inkscape:version="0.45+devel"
|
||||
version="1.0"
|
||||
sodipodi:docname="by.svg"
|
||||
inkscape:output_extension="org.inkscape.output.svg.inkscape">
|
||||
<defs
|
||||
id="defs2761" />
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#8b8b8b"
|
||||
borderopacity="1"
|
||||
gridtolerance="10000"
|
||||
guidetolerance="10"
|
||||
objecttolerance="10"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1"
|
||||
inkscape:cx="179"
|
||||
inkscape:cy="89.569904"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
width="120px"
|
||||
height="42px"
|
||||
inkscape:showpageshadow="false"
|
||||
inkscape:window-width="1198"
|
||||
inkscape:window-height="624"
|
||||
inkscape:window-x="396"
|
||||
inkscape:window-y="242" />
|
||||
<metadata
|
||||
id="metadata2764">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1">
|
||||
<g
|
||||
transform="matrix(0.9937728,0,0,0.9936696,-177.69267,6.25128e-7)"
|
||||
id="g260"
|
||||
inkscape:export-filename="/mnt/hgfs/Bov/Documents/Work/2007/cc/identity/srr buttons/big/by.png"
|
||||
inkscape:export-xdpi="300.23013"
|
||||
inkscape:export-ydpi="300.23013">
|
||||
<path
|
||||
id="path3817_1_"
|
||||
nodetypes="ccccccc"
|
||||
d="M 181.96579,0.51074 L 296.02975,0.71338 C 297.6235,0.71338 299.04733,0.47705 299.04733,3.89404 L 298.90768,41.46093 L 179.08737,41.46093 L 179.08737,3.75439 C 179.08737,2.06934 179.25046,0.51074 181.96579,0.51074 z"
|
||||
style="fill:#aab2ab" />
|
||||
|
||||
<path
|
||||
d="M 297.29636,0 L 181.06736,0 C 179.82078,0 178.80613,1.01416 178.80613,2.26074 L 178.80613,41.75732 C 178.80613,42.03906 179.03513,42.26757 179.31687,42.26757 L 299.04734,42.26757 C 299.32908,42.26757 299.55808,42.03905 299.55808,41.75732 L 299.55808,2.26074 C 299.55807,1.01416 298.54343,0 297.29636,0 z M 181.06735,1.02148 L 297.29635,1.02148 C 297.98043,1.02148 298.53658,1.57714 298.53658,2.26074 C 298.53658,2.26074 298.53658,18.20898 298.53658,29.71045 L 215.19234,29.71045 C 212.14742,35.21631 206.28121,38.95459 199.54879,38.95459 C 192.81344,38.95459 186.94869,35.21973 183.90524,29.71045 L 179.8276,29.71045 C 179.8276,18.20899 179.8276,2.26074 179.8276,2.26074 C 179.82761,1.57715 180.38376,1.02148 181.06735,1.02148 z"
|
||||
id="path263" />
|
||||
|
||||
<g
|
||||
enable-background="new "
|
||||
id="g265">
|
||||
<path
|
||||
d="M 253.07761,32.95605 C 253.39499,32.95605 253.68503,32.98437 253.94773,33.04003 C 254.20945,33.09569 254.43308,33.18749 254.62058,33.31542 C 254.8071,33.44237 254.95261,33.6123 255.05515,33.82323 C 255.15769,34.03514 255.20945,34.29589 255.20945,34.60741 C 255.20945,34.94335 255.13328,35.22264 254.97996,35.44628 C 254.82762,35.67089 254.60105,35.85351 254.30223,35.99706 C 254.71434,36.11522 255.02196,36.32226 255.22508,36.61815 C 255.4282,36.91404 255.52977,37.27049 255.52977,37.68749 C 255.52977,38.02343 255.46434,38.31444 255.33348,38.56054 C 255.20262,38.80566 255.02586,39.00683 254.80516,39.1621 C 254.58348,39.31835 254.33055,39.43358 254.04735,39.5078 C 253.76317,39.583 253.47215,39.6201 253.17235,39.6201 L 249.936,39.6201 L 249.936,32.95604 L 253.07761,32.95604 L 253.07761,32.95605 z M 252.89011,35.65137 C 253.15183,35.65137 253.36667,35.58887 253.53562,35.46485 C 253.70359,35.34083 253.78757,35.13965 253.78757,34.86036 C 253.78757,34.70509 253.75925,34.57716 253.70359,34.47852 C 253.64695,34.37891 253.57273,34.30176 253.47898,34.24512 C 253.38523,34.18946 253.27781,34.15039 253.15671,34.12891 C 253.03561,34.10743 252.90866,34.09668 252.77878,34.09668 L 251.40476,34.09668 L 251.40476,35.65137 L 252.89011,35.65137 z M 252.97604,38.47949 C 253.11959,38.47949 253.25631,38.46582 253.38717,38.4375 C 253.51803,38.40918 253.63326,38.3623 253.73385,38.29785 C 253.83346,38.23242 253.91256,38.14355 253.97213,38.03125 C 254.0317,37.91992 254.061,37.77637 254.061,37.60254 C 254.061,37.26074 253.96432,37.0166 253.77096,36.87012 C 253.5776,36.72461 253.32174,36.65137 253.00436,36.65137 L 251.40475,36.65137 L 251.40475,38.47949 L 252.97604,38.47949 z"
|
||||
id="path267"
|
||||
style="fill:#ffffff" />
|
||||
|
||||
<path
|
||||
d="M 255.78854,32.95605 L 257.43209,32.95605 L 258.99264,35.58789 L 260.54342,32.95605 L 262.17721,32.95605 L 259.70358,37.0625 L 259.70358,39.62012 L 258.23483,39.62012 L 258.23483,37.02539 L 255.78854,32.95605 z"
|
||||
id="path269"
|
||||
style="fill:#ffffff" />
|
||||
|
||||
</g>
|
||||
|
||||
<g
|
||||
id="g5908_1_"
|
||||
transform="matrix(0.872921,0,0,0.872921,50.12536,143.2144)">
|
||||
|
||||
<path
|
||||
id="path5906_1_"
|
||||
cx="296.35416"
|
||||
ry="22.939548"
|
||||
cy="264.3577"
|
||||
type="arc"
|
||||
rx="22.939548"
|
||||
d="M 186.90065,-141.46002 C 186.90623,-132.77923 179.87279,-125.73852 171.19257,-125.73291 C 162.51235,-125.72736 155.47051,-132.76025 155.46547,-141.44098 C 155.46547,-141.44714 155.46547,-141.45331 155.46547,-141.46002 C 155.46043,-150.14081 162.49333,-157.18152 171.17355,-157.18658 C 179.8549,-157.19213 186.89561,-150.15924 186.90065,-141.47845 C 186.90065,-141.4729 186.90065,-141.46619 186.90065,-141.46002 z"
|
||||
style="fill:#ffffff" />
|
||||
|
||||
<g
|
||||
id="g5706_1_"
|
||||
transform="translate(-289.6157,99.0653)">
|
||||
<path
|
||||
id="path5708_1_"
|
||||
d="M 473.57574,-253.32751 C 477.06115,-249.8421 478.80413,-245.5736 478.80413,-240.52532 C 478.80413,-235.47594 477.09136,-231.25329 473.66582,-227.85741 C 470.03051,-224.28081 465.734,-222.49309 460.77635,-222.49309 C 455.87858,-222.49309 451.65648,-224.26628 448.11122,-227.81261 C 444.56541,-231.35845 442.79277,-235.59563 442.79277,-240.52532 C 442.79277,-245.45391 444.56541,-249.7213 448.11122,-253.32751 C 451.56642,-256.81402 455.7885,-258.557 460.77635,-258.557 C 465.82465,-258.55701 470.09039,-256.81403 473.57574,-253.32751 z M 450.45776,-250.98267 C 447.51104,-248.00629 446.03823,-244.51978 446.03823,-240.52033 C 446.03823,-236.52198 447.49651,-233.06507 450.41247,-230.14966 C 453.32897,-227.23316 456.80096,-225.77545 460.82952,-225.77545 C 464.85808,-225.77545 468.35967,-227.24768 471.33605,-230.19385 C 474.16198,-232.9303 475.57549,-236.37091 475.57549,-240.52033 C 475.57549,-244.63837 474.13903,-248.13379 471.26781,-251.00501 C 468.39714,-253.87568 464.9179,-255.31159 460.82952,-255.31159 C 456.74112,-255.31158 453.28314,-253.86841 450.45776,-250.98267 z M 458.21225,-242.27948 C 457.76196,-243.26117 457.08795,-243.75232 456.18903,-243.75232 C 454.59986,-243.75232 453.80558,-242.68225 453.80558,-240.54321 C 453.80558,-238.40368 454.59986,-237.33471 456.18903,-237.33471 C 457.23841,-237.33471 457.98795,-237.85546 458.43769,-238.89922 L 460.64045,-237.72625 C 459.59052,-235.86077 458.01536,-234.92779 455.91496,-234.92779 C 454.29506,-234.92779 452.99733,-235.42449 452.0229,-236.4168 C 451.0468,-237.41021 450.56016,-238.77953 450.56016,-240.52532 C 450.56016,-242.24035 451.06245,-243.60186 452.06764,-244.61034 C 453.07283,-245.61888 454.32466,-246.12291 455.82545,-246.12291 C 458.04557,-246.12291 459.63526,-245.24803 460.59626,-243.50005 L 458.21225,-242.27948 z M 468.57562,-242.27948 C 468.12475,-243.26117 467.46417,-243.75232 466.5932,-243.75232 C 464.97217,-243.75232 464.16107,-242.68225 464.16107,-240.54321 C 464.16107,-238.40368 464.97217,-237.33471 466.5932,-237.33471 C 467.64429,-237.33471 468.38037,-237.85546 468.80048,-238.89922 L 471.05249,-237.72625 C 470.00421,-235.86077 468.43127,-234.92779 466.33478,-234.92779 C 464.7171,-234.92779 463.42218,-235.42449 462.44831,-236.4168 C 461.47614,-237.41021 460.98896,-238.77953 460.98896,-240.52532 C 460.98896,-242.24035 461.48341,-243.60186 462.47181,-244.61034 C 463.45966,-245.61888 464.71711,-246.12291 466.24531,-246.12291 C 468.4615,-246.12291 470.04896,-245.24803 471.0066,-243.50005 L 468.57562,-242.27948 z" />
|
||||
|
||||
</g>
|
||||
|
||||
</g>
|
||||
|
||||
<g
|
||||
id="g275">
|
||||
<circle
|
||||
cx="255.55124"
|
||||
cy="15.31348"
|
||||
r="10.80664"
|
||||
id="circle277"
|
||||
sodipodi:cx="255.55124"
|
||||
sodipodi:cy="15.31348"
|
||||
sodipodi:rx="10.80664"
|
||||
sodipodi:ry="10.80664"
|
||||
style="fill:#ffffff" />
|
||||
|
||||
<g
|
||||
id="g279">
|
||||
<path
|
||||
d="M 258.67819,12.18701 C 258.67819,11.77051 258.3403,11.4331 257.92526,11.4331 L 253.15182,11.4331 C 252.73678,11.4331 252.39889,11.7705 252.39889,12.18701 L 252.39889,16.95996 L 253.72994,16.95996 L 253.72994,22.61182 L 257.34713,22.61182 L 257.34713,16.95996 L 258.67818,16.95996 L 258.67818,12.18701 L 258.67819,12.18701 z"
|
||||
id="path281" />
|
||||
|
||||
<circle
|
||||
cx="255.53854"
|
||||
cy="9.1723604"
|
||||
r="1.63281"
|
||||
id="circle283"
|
||||
sodipodi:cx="255.53854"
|
||||
sodipodi:cy="9.1723604"
|
||||
sodipodi:rx="1.63281"
|
||||
sodipodi:ry="1.63281" />
|
||||
|
||||
</g>
|
||||
|
||||
<path
|
||||
clip-rule="evenodd"
|
||||
d="M 255.5239,3.40723 C 252.29148,3.40723 249.55515,4.53516 247.31589,6.79102 C 245.01804,9.12452 243.8696,11.88672 243.8696,15.07569 C 243.8696,18.26466 245.01804,21.00733 247.31589,23.30225 C 249.61374,25.59668 252.35007,26.74414 255.5239,26.74414 C 258.73679,26.74414 261.52195,25.58789 263.87742,23.27295 C 266.09715,21.07568 267.2075,18.34326 267.2075,15.07568 C 267.2075,11.8081 266.07762,9.04687 263.8198,6.79101 C 261.56003,4.53516 258.79538,3.40723 255.5239,3.40723 z M 255.55319,5.50684 C 258.20163,5.50684 260.45065,6.44092 262.30026,8.30811 C 264.1694,10.15528 265.10397,12.41114 265.10397,15.07569 C 265.10397,17.75928 264.18893,19.98633 262.35885,21.75587 C 260.43014,23.66212 258.16256,24.61476 255.55319,24.61476 C 252.94284,24.61476 250.69381,23.67189 248.80612,21.78517 C 246.91647,19.89845 245.97311,17.66212 245.97311,15.0757 C 245.97311,12.48879 246.92721,10.23341 248.83541,8.30812 C 250.6655,6.44092 252.90475,5.50684 255.55319,5.50684 z"
|
||||
id="path285"
|
||||
style="fill-rule:evenodd" />
|
||||
|
||||
</g>
|
||||
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 10 KiB |
207
main.typ
207
main.typ
@ -1,6 +1,9 @@
|
||||
//#import "@preview/clean-acmart:0.0.1": acmart, acmart-ccs, acmart-keywords, acmart-ref, to-string
|
||||
#import "clean-acmart.typ": acmart
|
||||
#import "@preview/cetz:0.3.4"
|
||||
#import "@preview/lilaq:0.3.0" as lq
|
||||
#import "@preview/cetz:0.3.2"
|
||||
#import "@preview/cetz-plot:0.1.1": chart as cetz_chart
|
||||
|
||||
#let title = [Dataflow Analysis for Compiler Optimization]
|
||||
#let authors = (
|
||||
@ -38,14 +41,50 @@
|
||||
#set heading(numbering: "1.1.1")
|
||||
|
||||
= Abstract
|
||||
// define DFA and CO here or in introduction
|
||||
todo
|
||||
Dataflow analysis is an important part of compiler optimization since it allows to eliminate parts of the code with various techniques such as: constant propagation, dead code elimination, branch elimination. This work aims to look at the advantages and disadvantages of using dataflow analysis, how it is already used in current compilers, on which programming languages / immediate representations it operates and what limitations still exist. \
|
||||
For this purpose we conducted a systematic literature in which we analyzed 15 publications selected from 571 entries. Finally following conclusions were drawn: // TODO
|
||||
|
||||
|
||||
= Introduction
|
||||
todo
|
||||
Program performance remains a large concern in modern computing and programming, since it has a direct impact on user and developer experience. As software is becoming more complex, manual optimization is increasingly complex and harder for developers to implement.
|
||||
Another problem with this increasing complexity is that large codebases are spread out over more files, which also makes it harder for developers to keep an overview and to implement optimizations. Because of these reasons automatic optimization is needed in compilers. \
|
||||
#figure(
|
||||
caption: [C code and respective SSA form],
|
||||
kind: "raw",
|
||||
grid(
|
||||
columns: (1fr, 1fr),
|
||||
```C
|
||||
int x = 8;
|
||||
x = x - 2;
|
||||
if (x < 4)
|
||||
x = 10;
|
||||
else
|
||||
x = 12;
|
||||
int y = x * 2;
|
||||
```,
|
||||
/*```
|
||||
x₁ = 8
|
||||
x₂ = x₁ - 2
|
||||
if (x₂ < 4)
|
||||
x₃ = 10
|
||||
else
|
||||
x₄ = 12
|
||||
x₅ = ɸ(x₃, x₄)
|
||||
y₁ = x₅ * 2
|
||||
```*/
|
||||
image("ssa-example.svg", height: 16em)
|
||||
)
|
||||
) <ssa_form_example>
|
||||
Many modern compilers and analysis tools operate on a Static Single-Assignment (SSA) form @cooper_keith_d_engineering_nodate @cytron_efficiently_1991. The SSA form works by assigning each variable only once. This is done by creating multiple subvariable $x_1, x_2, ...$ for each variable $x$. After a branch in the program a #{sym.Phi}-Node is used to select the new value of the variable based on branch executed.
|
||||
An example of the SSA form can be seen in @ssa_form_example. On the left is a simple C code in a function body and on right is the respective SSA form of the C code. \
|
||||
Dataflow analysis is a technique used to gather information about the state of variables throughout the flow of the program. It plays an important role in many compilers, since by analyzing how, where and what variables are assigned and how these variables are used, many complex optimizations, which require context from the surrounding code, can be implemented. \
|
||||
Dataflow analysis is an evolving field where regularly new techniques are created and older techniques improved. Different compilers and analysis framework implement different methods and optimizations with dataflow analysis. This work aims to summarrize the current state and past achievements of this technology.
|
||||
This work is divided into the following sections in @methodology_c the methology used to create this work is described. // TODO
|
||||
// TODO explain constant propagation, ...
|
||||
// TODO LLVM, GCC as examples
|
||||
|
||||
= Methodology
|
||||
This publication is created following the process described in @process_fig. The protocol for the review is divided up into the object of the research see @research_questions_s, the search strategy see @sas_s, the selection criteria see @selection_criteria_s and the data extraction strategy see @data_extraction_s.
|
||||
= Methodology <methodology_c>
|
||||
This work is created following the process described in @process_fig. The protocol for the review is divided up into the object of the research see @research_questions_s, the search strategy see @sas_s, the selection criteria see @selection_criteria_s and the data extraction strategy see @data_extraction_s.
|
||||
#place(
|
||||
bottom + center,
|
||||
scope: "parent",
|
||||
@ -68,7 +107,6 @@ This goal has been defined in two research questions:
|
||||
This questions aims to identify how DFA is already used in current compilers, what optimizations are done with it and if it is used during normal compilation or if it has to be explicitly enabled.
|
||||
|
||||
== Search and selection strategy <sas_s>
|
||||
Our search strategy consisted of 4 steps as seen in @sas_fig. \
|
||||
#figure(
|
||||
caption: [Search string used in electronic databases],
|
||||
kind: "raw",
|
||||
@ -86,12 +124,14 @@ Our search strategy consisted of 4 steps as seen in @sas_fig. \
|
||||
```
|
||||
]
|
||||
) <sas_search_string>
|
||||
Our search strategy consisted of 5 steps as seen in @sas_fig. \
|
||||
The papers from the first steps are collected from the electronic databases ACM Digital Library, IEEE Xplore, Springer Link with the search string seen in @sas_search_string.
|
||||
The search string in @sas_search_string was created using the research questions in @research_questions_s and was always applied to the full text of the papers. \
|
||||
In the second step all duplicates which where returned from multiple databases where removed from the results. \
|
||||
In the second step all duplicates which where returned from multiple databases where removed from the results and the amount was limited to fit the scope of this paper. \
|
||||
In the third step the selection was filtered by applying all selection criteria from @selection_criteria_s. \
|
||||
In the fourth step I snowballed the previously acquired results. This was to find relevant papers which where not included because of either the search string or the search criteria. \
|
||||
Afterwards all papers of the snowballing where evaluated based on the data extraction items mentioned in @data_extraction_s.
|
||||
In the fourth step we snowballed the previously acquired results. This was to find relevant papers which where not included because of either the search string or the search criteria. \
|
||||
Afterwards all papers found via the snowballing where filtered again by applying the selection criteria in @selection_criteria_s. \
|
||||
In the end all papers from the third step and the papers of the snowballing where evaluated based on the data extraction items mentioned in @data_extraction_s.
|
||||
#place(
|
||||
auto,
|
||||
scope: "parent",
|
||||
@ -113,7 +153,8 @@ Afterwards all papers of the snowballing where evaluated based on the data extra
|
||||
rect((bs.at(0)+1.5, -(bs.at(1)+0.3)), (rel: bs), name: "dup")
|
||||
rect((bs.at(0)*2+2.25, -(bs.at(1)+0.3)), (rel: bs), name: "sel")
|
||||
rect((bs.at(0)*3+3, -(bs.at(1)+0.3)), (rel: bs), name: "snow")
|
||||
rect((bs.at(0)*4+3.75, -(bs.at(1)+0.3)), (rel: bs), name: "inc")
|
||||
rect((bs.at(0)*4+3.75, -(bs.at(1)+0.3)), (rel: bs), name: "reap")
|
||||
rect((bs.at(0)*5+4.25, -(bs.at(1)+0.3)), (rel: bs), name: "inc")
|
||||
|
||||
line("acm.east", (rel: (0.75, 0)), name: "dlu")
|
||||
line("ieee.east", (rel: (0.75, 0)))
|
||||
@ -124,15 +165,17 @@ Afterwards all papers of the snowballing where evaluated based on the data extra
|
||||
line("dl.50%", "dup.west")
|
||||
line("dup.east", "sel.west")
|
||||
line("sel.east", "snow.west")
|
||||
line("snow.east", "inc.west")
|
||||
line("snow.east", "reap.west")
|
||||
line("reap.east", "inc.west")
|
||||
|
||||
content("acm", align(center)[ACM Digital Library \ n = ])
|
||||
content("ieee", align(center)[IEEE Xplore \ n = ])
|
||||
content("springer", align(center)[Springer Link \ n = ])
|
||||
content("dup", align(center)[Duplicate removal \ n = ])
|
||||
content("sel", align(center)[Application of \ selection criteria \ n = ])
|
||||
content("snow", align(center)[Snowballing \ n = ])
|
||||
content("inc", align(center)[Publications included \ n = ])
|
||||
content("acm", align(center)[ACM Digital Library \ n = 3594])
|
||||
content("ieee", align(center)[IEEE Xplore \ n = 1720])
|
||||
content("springer", align(center)[Springer Link \ n = 786])
|
||||
content("dup", align(center)[Duplicate removal and \ preliminary filtering \ n = 471])
|
||||
content("sel", align(center)[Application of \ selection criteria \ n = 10])
|
||||
content("snow", align(center)[Snowballing \ n = 110])
|
||||
content("reap", align(center)[Rreapplication \ of selection criteria \ n = 15])
|
||||
content("inc", align(center)[Publications included \ n = 15])
|
||||
})
|
||||
) <sas_fig>
|
||||
]
|
||||
@ -156,15 +199,13 @@ _IC3_ is to further include publications which directly provide an implementatio
|
||||
#set enum(numbering: (.., i) => "EC" + str(i))
|
||||
+ Publications which discuss DFA in a non-compiler context.
|
||||
+ Publications written in a language other than english.
|
||||
+ Secondary and tertiary publications (e.g., systematic literaturer reviews, surveys).
|
||||
+ Secondary and tertiary publications (e.g., systematic literature reviews, surveys).
|
||||
+ Publications in the form of tutorial papers, short papers, poster papers, editorials.
|
||||
+ Publications for which the full text is not available.
|
||||
+ Publications published before 2010.
|
||||
#v(10pt)
|
||||
]
|
||||
_EC1_ is to exclude publications which talk about DFA in other contexts which are not relevant to compiler optimization. \
|
||||
_EC2-EC5_ are to exclude publications which do not provide enough information to include them in this publication. \
|
||||
_EC6_ is to make sure the publications are still relevant.
|
||||
_EC2-EC5_ are to exclude publications which do not provide enough information to include them in this publication.
|
||||
|
||||
== Data extraction <data_extraction_s>
|
||||
Based on the research questions I collected 9 data items to exrtract from all included publications. @data_extraction_table lists all data items. \
|
||||
@ -205,15 +246,121 @@ All data items were extracted from the full text of all included publications.
|
||||
]
|
||||
)
|
||||
|
||||
#colbreak()
|
||||
= Findings
|
||||
In this chapter we list our findings from the conducted systematic literature analysis.
|
||||
|
||||
== Demographic
|
||||
#v(1em, weak: true)
|
||||
#figure(
|
||||
caption: "Publication years of the publications",
|
||||
{
|
||||
let data = (
|
||||
(1973, 1),
|
||||
(1997, 1),
|
||||
(2010, 2),
|
||||
(2011, 2),
|
||||
(2012, 1),
|
||||
(2013, 2),
|
||||
(2015, 1),
|
||||
(2018, 1),
|
||||
(2019, 1),
|
||||
(2020, 2),
|
||||
(2024, 1)
|
||||
)
|
||||
lq.diagram(
|
||||
width: 8.5cm,
|
||||
xlim: (1972, 2026),
|
||||
ylim: (0, 2.5),
|
||||
yaxis: (subticks: none, ticks: range(0, 3)),
|
||||
xaxis: (ticks: range(1975, 2026, step: 5)),
|
||||
lq.bar(
|
||||
data.map(v => v.at(0)),
|
||||
data.map(v => v.at(1))
|
||||
)
|
||||
)
|
||||
}
|
||||
) <demographic_pub_year>
|
||||
#figure(
|
||||
caption: "Target languages of the publications",
|
||||
{
|
||||
let data = (
|
||||
("None", 1),
|
||||
("Custom", 1),
|
||||
("C", 3),
|
||||
("LLVM IR", 5),
|
||||
("Java Bytecode", 2),
|
||||
("Graal IR", 1),
|
||||
("SSA of Java", 2)
|
||||
)
|
||||
|
||||
cetz.canvas({
|
||||
//let colors = (red, eastern, green, blue, navy, purple, maroon, orange)
|
||||
let colors = gradient.linear(..color.map.rainbow.map(v => v.darken(20%).saturate(20%)))
|
||||
|
||||
cetz_chart.piechart(
|
||||
data,
|
||||
value-key: 1,
|
||||
label-key: 0,
|
||||
radius: 3,
|
||||
slice-style: colors,
|
||||
inner-radius: 0,
|
||||
inner-label: (content: (value, _) => [#text(white, str(value))], radius: 150%),
|
||||
outer-label: (content: (value, _) => [], radius: 0%),
|
||||
legend: (
|
||||
position: "east",
|
||||
anchor: "south",
|
||||
orientation: ttb,
|
||||
offset: (1.7cm, -2.5cm)
|
||||
)
|
||||
)
|
||||
})
|
||||
}
|
||||
) <demographic_target_lang>
|
||||
As seen in @demographic_pub_year most of the analyzed publication are from the last 15 years, which indicates that this field is still actively being researched and explore, but research has already start back in 1983. \
|
||||
@demographic_target_lang shows a strong trend towards implementing DFA optimizations either with LLVM directly or by operating on the LLVM IR, while java is either directly used as bytecode or at SSA representation of Java.
|
||||
|
||||
== RQ1: Advantages and disadvantages of using Dataflow analysis for compiler optimization
|
||||
DFA makes many big compiler optimizations possible but it also brings many trade-offs and not just for performance.
|
||||
These optimizations eliminate unused code and simplify expressions, which reduces execution time and memory footprint during runtime.
|
||||
[*P1*] is one of the first publications talking about DFA and how it allows to use previously existing optimizations, which could only be applied on code sections without branches, with branching by checking how data flows through the branches. Later publications [*P2*, *P5*]
|
||||
describe ways to apply these optimization interprocedurally and across thread synchronisation boundaries. But [*P5*] also describes, that programs must be well synchronized, otherwise DFA can not be used because of possible data races. \
|
||||
=== Analysis performance
|
||||
While perofrmance is not the biggest concern for DFA, since it runs at compile-time and accuracy is more important [*P4*], many publications [*P4*, *P6*, *P14*, *P15*] have investigated how to improve the performance of DFA. This is done with several techniques: In [*P4*, *P6*] different function calls are run on different threads, but it has the problem of creating and queue a task for each function, which can lead to a big overhead. In [*P6*] independent branches are also run on separate threads. A big problem with both approaches is to avoid, that some functions could be queued for analysis be more than one thread, which leads to unnecessary redundancy. \
|
||||
Another approach [*P14*] is to pipeline the function calls. This is done by analyzing all variables, which do not depend on any function calls. When the function calls have finished being analyzed, the variables, which depend on that function call are analyzed. Thereby more parallel work is possible.
|
||||
=== Implementation complexity
|
||||
Another problem with DFA is the difficulty to implement optimizations with it [*P3*, *P11*]. DFA is often also deeply entangled with the compiler internals, which makes it difficult to reuse existing optimizations with other compilers or implement new optimizations quickly and it is complicated to implemented, as seen in LLVM: "simple peephole optimizations in the LLVM instcombine pass contain approximately 30000 lines of complex C++ code, despite the transformations being simple" [*P11*] \
|
||||
One solutions to this problem is described in [*P3*] by implementing a library in Haskell which performs the dataflow analysis and provides an interface, which "is made possible by sophisticated aspects of Haskell’s type system, such as higher-rank polymorphism, GADTs, and type functions" [*P3*], to implement various optimizations, which also then can be reused for other compilers. The biggest drawback of this library is it's limited to compilers implemented in Haskell. \
|
||||
[*P11*] describes a domain specific language to implement LLVM optimization passes. This is done by a having a simple language for directly implementing the logic of the optimization, while a custom transpiler then converts it into a LLVM pass written in C++. Since the LLVM pass is implemented in a more generic way to fit this purpose, it leads to a moderate compile time increase. There is no formal verification done on the implemented optimization pass. Because of these disadvantages it is a great tool to quickly implement, test and iterate optimizations, but for a more permanent passes, hand-written C++ code should be used.
|
||||
|
||||
== RQ2: Usage of dataflow analysis in current compilers
|
||||
The Glasgow Haskell Compiler (GHC), LLVM and GCC are good examples for compilers which already extensively use DFA to implement optimizations.
|
||||
These optimizations include common sub-expression elimination [*P1*, *P7*, *P13*], copy propagation [*P5*, *P7*], constant propagation [*P1*, conditional branch elimination [*P2*] and dead code elimination [*P13*].
|
||||
// TODO
|
||||
|
||||
= Conclusion
|
||||
Our findings show that DFA is already extensively used in current compilers and brings big advantages for runtime speed. The cost of this is a higher compilation duration, which makes it unsuitable for JIT compilation. Furthermore DFA allows complex optimizations across branches and function boundaries which would not be possible with traditional straight-line optimizations. \
|
||||
The high implementation complexity and the deep entangled with the compiler internals also poses a big problem for advancing this field further.
|
||||
The recent release of new publications on this topic indicates that researchers are continuisly searching for better and faster ways to implement DFA and to make better use of the analysis results. \
|
||||
The adaptability of LLVM and the associated immediate representation makes it an invaluable platform to do testing and research with DFA.
|
||||
|
||||
#pagebreak(weak: true)
|
||||
#set heading(numbering: "A.a.a")
|
||||
#counter(heading).update(0)
|
||||
|
||||
#set page(flipped: true, columns: 1)
|
||||
= SLR Results
|
||||
#{
|
||||
set table(stroke: (x, _) => if x in (1, 4, 6) { (x: 2pt, y: 1pt) } else { 1pt })
|
||||
table(
|
||||
columns: (auto, auto, auto, auto, auto, auto, 6em, 4em, auto, auto),
|
||||
inset: (x: 5pt, y: 3pt),
|
||||
..csv("pubs.csv").flatten()
|
||||
)
|
||||
}
|
||||
|
||||
#set page(flipped: false, columns: 2)
|
||||
#pagebreak(weak: true)
|
||||
#set heading(numbering: none)
|
||||
#bibliography("refs.bib", title: "References", style: "association-for-computing-machinery")
|
||||
|
||||
/*
|
||||
#colbreak(weak: true)
|
||||
#set heading(numbering: "A.a.a")
|
||||
|
||||
= Artifact Appendix
|
||||
In this section we show how to reproduce our findings.
|
||||
*/
|
||||
|
||||
|
||||
16
pubs.csv
Normal file
16
pubs.csv
Normal file
@ -0,0 +1,16 @@
|
||||
ID,D1,D2,D3,D4,D5,D6,D7,D8,D9
|
||||
P1,"Kildall, Gary A.",1973,A unified approach to global program optimization,Allows straight-line optimization techniques for branch structure,,General Techniques,None,"Constant Propagation, Common Subexpression Elimination, Register Optimization",
|
||||
P2,Rastislav Bodik; Rajiv Gupta; Mary Lou Soffa,1997,Interprocedural conditional branch elimination,Reduction of instruction count,Exponential/Polynomial worst-case time complexity,ICC,C,"Conditional Branch Elimination, Elimination of correlated conditionals and operations",
|
||||
P3,"Ramsey, Norman; Dias, João; Peyton Jones, Simon",2010,"Hoopl: a modular, reusable library for dataflow analysis and transformation",Reusable library for DFA,"DFA typically entangled with compiler, Algorithms complicated and hard to understand","Library, used by GHC",Custom,"Interleaved analysis and rewriting, speculative rewriting, computing fixed points, dynamic fault isolation",Only usable from Haskell
|
||||
P4,"Edvinsson, Marcus; Lowe, Welf",2010,A multi-threaded approach for data-flow analysis,Accuracy more important than speed since at compile time,"Low usability for JIT because of time consumption, DFA is computation intense, DFA often implemented sequentially",Custom,"SSA, Java","High speed-up for analysis, for benchmarks without benefit max loss of 13% speed",Only speed-up of 1.78 on 8 cores
|
||||
P5,"Joisha, Pramod G.; Schreiber, Robert S.; Banerjee, Prithviraj; Boehm, Hans J.; Chakrabarti, Dhruva R.",2011,A technique for the effective and automatic reuse of classical compiler optimizations on multithreaded code,,"Sequential transformations can not be applied to parallel code, Need to watch out for data races and data synchronization",GCC,C,"Bidirectional DFA across synchronizations in well-synchronized programs, Can reuse existing optimizations, Value numbering, Copy propagation",
|
||||
P6,"Edvinsson, Marcus; Lundberg, Jonas; Löwe, Welf",2011,Parallel points-to analysis for multi-core machines,Points-To Analysis analyses whole program,SSA nodes in Points-to SSA are sequentially dependent,Custom,"SSA, Java",Parallel Points-to Analysis,
|
||||
P7,"Tang, Xiaolong; Järvi, Jaakko",2012,Summary-based data-flow analysis that understands regular composite objects and iterators,,Hard to make assumptions about user-defined types,LLVM,LLVM IR,"Common Sub-expression elimination, Copy propagation, Equational reasoning",
|
||||
P8,"Urban, Bernhard; Steinlechner, Harald",2013,Implementing a Java JIT compiler in Haskell: case study,,,Custom JIT,Java Bytecode,Liveness Analysis,
|
||||
P9,"Duboscq, Gilles; Stadler, Lukas; Würthinger, Thomas; Simon, Doug; Wimmer, Christian; Mössenböck, Hanspeter",2013,Graal IR: An Extensible Declarative Intermediate Representation,Easier optimization implementation with Graph-IR,,"GraalVM, uses P3",Java Bytecode,IR which is simple to run optimizations on,Not implemented: commutative edges on nodes for better congruent detection
|
||||
P10,"Zaidi, Ali Mustafa; Greaves, David",2015,Value State Flow Graph: A Dataflow Compiler IR for Accelerating Control-Intensive Code in Spatial Hardware,Performance improvement through execution of dataflow graph,,Custom LLVM Backend,LLVM IR,,"Structs, Multidimensional-Arrays not supported"
|
||||
P11,"Ginsbach, Philip; Crawford, Lewis; O'Boyle, Michael F. P.",2018,CAnDL: a domain specific language for compiler analysis,DSL for optimization implementation makes implementation simpler and iterations quicker,"Optimizations are hard to implement in LLVM, Simple peephole optimization is 30000 LOC",DSL to LLVM Pass,LLVM IR,,"Moderate compile time increase, no formal verification"
|
||||
P12,"Pathade, Komal; Khedker, Uday P.",2019,Path sensitive MFP solutions in presence of intersecting infeasible control flow path segments,,Path insensitive solutions overapproximate data flow values,TCS Embedded Code Analyzer,C,"Reaching Definition, Def-Use Pairs, Unitialized Variables, 300% precision increase",100% analysis time increase
|
||||
P13,"Reissmann, Nico; Meyer, Jan Christian; Bahmann, Helge; Själander, Magnus",2020,RVSDG: An Intermediate Representation for Optimizing Compilers,,Structures like loops not encoded in SSA,Custom,LLVM IR,"Common Node Elimination, Dead Node Elimination",
|
||||
P14,"Shi, Qingkai; Zhang, Charles",2020,Pipelining bottom-up data flow analysis,,Calling dependence limit parallelism of bottom-up DFA,Custom based on LLVM,LLVM IR,2x to 3x speedup by relaxing calling dependence,Inline assembly and c++ stl not modeled
|
||||
P15,"Aigner, Christoph; Barany, Gergö; Mössenböck, Hanspeter",2024,Lazy Sparse Conditional Constant Propagation in the Sea of Nodes,,Detecting all compile time constant is undecidable problem,GraalVM,Sea of Nodes / Graal IR,Lazy iteration to reduce portion of necessary graph,
|
||||
|
25
refs.bib
25
refs.bib
@ -34,3 +34,28 @@
|
||||
year = {2021},
|
||||
pages = {469--503},
|
||||
}
|
||||
|
||||
@article{cytron_efficiently_1991,
|
||||
title = {Efficiently computing static single assignment form and the control dependence graph},
|
||||
volume = {13},
|
||||
issn = {0164-0925, 1558-4593},
|
||||
url = {https://dl.acm.org/doi/10.1145/115372.115320},
|
||||
doi = {10.1145/115372.115320},
|
||||
language = {en},
|
||||
number = {4},
|
||||
urldate = {2025-05-31},
|
||||
journal = {ACM Transactions on Programming Languages and Systems},
|
||||
author = {Cytron, Ron and Ferrante, Jeanne and Rosen, Barry K. and Wegman, Mark N. and Zadeck, F. Kenneth},
|
||||
month = oct,
|
||||
year = {1991},
|
||||
pages = {451--490},
|
||||
}
|
||||
|
||||
@book{cooper_keith_d_engineering_nodate,
|
||||
edition = {2nd edition},
|
||||
title = {Engineering a {Compiler}},
|
||||
isbn = {978-0-08-091661-3},
|
||||
language = {englisch},
|
||||
publisher = {Elsevier Science, 2011 Boston, MA : Safari},
|
||||
author = {{Cooper, Keith D.} and {Torczon, Linda}},
|
||||
}
|
||||
|
||||
16
ssa-example.dot
Normal file
16
ssa-example.dot
Normal file
@ -0,0 +1,16 @@
|
||||
digraph SSA {
|
||||
ranksep=0.3;
|
||||
node[shape=box];
|
||||
|
||||
start[label="x₁ = 8\lx₂ = x₁ - 2\lbranch x₂ < 4\l"];
|
||||
|
||||
start -> b0 [label="0"];
|
||||
start -> b1 [label="1"];
|
||||
|
||||
b0[label="x₄ = 12"];
|
||||
b1[label="x₃ = 10"];
|
||||
|
||||
b0 -> end;
|
||||
b1 -> end;
|
||||
end[label="x₅ = ɸ(x₃, x₄)\ly₁ = x₅ * 2\l"];
|
||||
}
|
||||
66
ssa-example.svg
Normal file
66
ssa-example.svg
Normal file
@ -0,0 +1,66 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
|
||||
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<!-- Generated by graphviz version 12.2.1 (0)
|
||||
-->
|
||||
<!-- Title: SSA Pages: 1 -->
|
||||
<svg width="140pt" height="204pt"
|
||||
viewBox="0.00 0.00 140.25 204.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 200)">
|
||||
<title>SSA</title>
|
||||
<polygon fill="white" stroke="none" points="-4,4 -4,-200 136.25,-200 136.25,4 -4,4"/>
|
||||
<!-- start -->
|
||||
<g id="node1" class="node">
|
||||
<title>start</title>
|
||||
<polygon fill="none" stroke="black" points="111.12,-196 20.12,-196 20.12,-138.5 111.12,-138.5 111.12,-196"/>
|
||||
<text text-anchor="start" x="28.12" y="-178.7" font-family="Times,serif" font-size="14.00">x₁ = 8</text>
|
||||
<text text-anchor="start" x="28.12" y="-162.2" font-family="Times,serif" font-size="14.00">x₂ = x₁ - 2</text>
|
||||
<text text-anchor="start" x="28.12" y="-145.7" font-family="Times,serif" font-size="14.00">branch x₂ < 4</text>
|
||||
</g>
|
||||
<!-- b0 -->
|
||||
<g id="node2" class="node">
|
||||
<title>b0</title>
|
||||
<polygon fill="none" stroke="black" points="57.25,-100 0,-100 0,-64 57.25,-64 57.25,-100"/>
|
||||
<text text-anchor="middle" x="28.62" y="-76.95" font-family="Times,serif" font-size="14.00">x₄ = 12</text>
|
||||
</g>
|
||||
<!-- start->b0 -->
|
||||
<g id="edge1" class="edge">
|
||||
<title>start->b0</title>
|
||||
<path fill="none" stroke="black" d="M53.1,-138.07C49.21,-129.31 44.92,-119.66 41.04,-110.93"/>
|
||||
<polygon fill="black" stroke="black" points="44.27,-109.58 37.01,-101.86 37.87,-112.42 44.27,-109.58"/>
|
||||
<text text-anchor="middle" x="51.61" y="-114.2" font-family="Times,serif" font-size="14.00">0</text>
|
||||
</g>
|
||||
<!-- b1 -->
|
||||
<g id="node3" class="node">
|
||||
<title>b1</title>
|
||||
<polygon fill="none" stroke="black" points="132.25,-100 75,-100 75,-64 132.25,-64 132.25,-100"/>
|
||||
<text text-anchor="middle" x="103.62" y="-76.95" font-family="Times,serif" font-size="14.00">x₃ = 10</text>
|
||||
</g>
|
||||
<!-- start->b1 -->
|
||||
<g id="edge2" class="edge">
|
||||
<title>start->b1</title>
|
||||
<path fill="none" stroke="black" d="M78.49,-138.07C82.49,-129.31 86.89,-119.66 90.88,-110.93"/>
|
||||
<polygon fill="black" stroke="black" points="94.05,-112.4 95.02,-101.85 87.68,-109.5 94.05,-112.4"/>
|
||||
<text text-anchor="middle" x="93.62" y="-114.2" font-family="Times,serif" font-size="14.00">1</text>
|
||||
</g>
|
||||
<!-- end -->
|
||||
<g id="node4" class="node">
|
||||
<title>end</title>
|
||||
<polygon fill="none" stroke="black" points="111.5,-41 19.75,-41 19.75,0 111.5,0 111.5,-41"/>
|
||||
<text text-anchor="start" x="27.75" y="-23.7" font-family="Times,serif" font-size="14.00">x₅ = ɸ(x₃, x₄)</text>
|
||||
<text text-anchor="start" x="27.75" y="-7.2" font-family="Times,serif" font-size="14.00">y₁ = x₅ * 2</text>
|
||||
</g>
|
||||
<!-- b0->end -->
|
||||
<g id="edge3" class="edge">
|
||||
<title>b0->end</title>
|
||||
<path fill="none" stroke="black" d="M39.33,-63.79C41.84,-59.74 44.6,-55.32 47.34,-50.9"/>
|
||||
<polygon fill="black" stroke="black" points="50.14,-53.02 52.45,-42.68 44.2,-49.33 50.14,-53.02"/>
|
||||
</g>
|
||||
<!-- b1->end -->
|
||||
<g id="edge4" class="edge">
|
||||
<title>b1->end</title>
|
||||
<path fill="none" stroke="black" d="M92.63,-63.79C90.05,-59.74 87.22,-55.32 84.4,-50.9"/>
|
||||
<polygon fill="black" stroke="black" points="87.48,-49.22 79.15,-42.67 81.58,-52.99 87.48,-49.22"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 3.3 KiB |
Loading…
x
Reference in New Issue
Block a user