Java Reference
In-Depth Information
procedure
foo
(
d
,
x
,
y
,
z
,
f
,
g
,
h
,
c
)
14
procedure
foo
if
(
d
15)
then goto L2
(
d
,
x
,
y
,
z
,
f
,
g
,
h
,
c
)
if
d
=
x
←
0
15
15
t
1
←
y
∗
z
y
←
x
+
t
1
call
then
x
←
0
y
←
x
+
y
∗
z
call
bar
(
x
,
y
)
z
←
2
bar
(
x
,
y
)
t
2
←
f
∗
g
z
←
2
t
3
←
t
2
+
h
if
f
∗
g
+
h
=
12
if
(
t
3
12)
then goto L1
then
y
←
y
←
3
16
3
x
←
4
x
←
4
L1:
goto L5
17
else
z
←
L2:
z
←
5
18
5
while
c
<
L3:
if
(
c
≥
12)
then goto L4
19
12
do
x
←
6
20
x
←
6
7
goto L3
y
←
y
←
7
y
←
8
L4:
8
goto L5
y
←
21
end
L5: end
22
(a)
(b)
Figure 14.6: (a) Source program; (b) Intermediate text and basic block
decomposition of the source program.
Figure 14.6 shows a program and the basic block partition of its intermediate
code. Each of the statements found at Marker
14
through Marker
22
begins a
new basic block. Notice that the block at Marker
15
contains a procedure call.
At this level of analysis, control flow within the procedure
bar
is obscured, so
the procedure call does not interrupt the basic block.
Although organization of statements into basic blocks may improve space
e
ciency, some reasons for avoiding basic blocks are as follows:
•
With respect to large address spaces, sparse flow graphs consume very
little space, even where program behavior is modeled at a relatively fine
level.
•
There is almost no time saved in organizing instructions into basic blocks,
especially if these blocksmust be “opened up” each time a node is visited.
•
There are two levels of data flow analysis typically associated with a
graph comprised of basic blocks:
local
data flow analysis establishes
