Documents for BodyInterceptor and some Tools

[wangzun66]

BodyInterceptor:

• LocalSplitter
• LocalPacker
• SSA
• TrapTightener
• EmptySwitchEliminator
• UnreachableCodeEliminator
• CopyPropagator
• LocalNameStandardizer

Tools:

• LocalLivenessAnalyser
• DominanceFinder

[bastihav]

Suggested change

	LocalSplitter is a <code>BodyInterceptor</code> that attempts to identify and separate uses of a local variable (as definition) that are independent of each other by renaming local variable.
	LocalSplitter is a <code>BodyInterceptor</code> that attempts to identify and separate uses of a local variable (as definition) that are independent of each other by renaming local variables.

[bastihav]

Suggested change

	As shown the example above, the local variable <code>l1</code> is defined twice. It can be split up into two new local variables: <code>l1#1</code> and <code>l1#2</code> because of the independency between its two definitions.
	As shown in the example above, the local variable <code>l1</code> is defined twice. It can be split up into two new local variables: <code>l1#1</code> and <code>l1#2</code> because the two definitions are independent of each other.

[bastihav]

Suggested change

	In the second example, the local variable <code>l2</code> is defined thrice. But it cannot be split up into three new local variables as in the first example. Because its definitions in the if-branches are not independent of each other. Therefore, it can be only split up into two local variables as shown in the figure.
	In the second example, the local variable <code>l2</code> is defined thrice. But it cannot be split up into three new local variables as in the first example, because its definitions in the if-branches are not independent of each other. Therefore, it can only be split up into two local variables as shown in the figure.

[bastihav]

Suggested change

We assume in the example above that only the<code>Stmt</code>:<code>l2 := 2</code>might throw an exception caught by the<code>Trap</code>which is labeled with<code>label3</code>. In the jimple body before running the TrapTightener, the protected area covered by the Trap contains three<code>Stmt</code>:<code>l1 := 1; l2 := 2; l2 := 3</code>. But an exception could only arise at the<code>Stmt</code>:<code>l2 := 2</code>. After the implementation of TrapTightener, we will get a contractible protected area which contains only the<code>Stmt</code>that might throw an exception, namely the<code>Stmt</code>:<code>l2 := 2</code>.

We assume in the example above that only the<code>Stmt</code>:<code>l2 := 2</code>might throw an exception caught by the<code>Trap</code>which is labeled with<code>label3</code>. In the jimple body before running the TrapTightener, the protected area covered by the Trap contains three<code>Stmts</code>:<code>l1 := 1; l2 := 2; l2 := 3</code>. But an exception could only arise at the<code>Stmt</code>:<code>l2 := 2</code>. After the implementation of TrapTightener, we will get a contractible protected area which contains only the<code>Stmt</code>that might throw an exception, namely the<code>Stmt</code>:<code>l2 := 2</code>.

[bastihav]

Suggested change

	EmptySwitchEliminator is a<code>BodyInterceptor</code>that removes the empty switch statement which contains only the default case.
	EmptySwitchEliminator is a<code>BodyInterceptor</code>that removes empty switch statements which contains only the default case.

[bastihav]

Suggested change

	As shown in the example above, the switch statement in the jimple body always takes the default action. After running EmptySwitchEliminator, the switch statement is replaced with the<code>GotoStmt</code>for default case.
	As shown in the example above, the switch statement in the jimple body always takes the default action. After running EmptySwitchEliminator, the switch statement is replaced with a <code>GotoStmt</code> to the default case.

[bastihav]

Suggested change

	* There're no definitions of<code>b</code>on any path from<code>a = b</code>to<code>c = use(a)</code>.
	* There are no definitions of<code>b</code>on any path from<code>a = b</code>to<code>c = use(a)</code>.

[bastihav]

Suggested change

	In the example for global copy propagation, the first used<code>l1</code>is replaced with<code>l0</code>, but the second used<code>l1</code>cannot be replace with<code>l3</code>, because the second condition is not satisfied.
	In the example for global copy propagation, the first used<code>l1</code>is replaced with<code>l0</code>, but the second used<code>l1</code>cannot be replaced with<code>l3</code>, because the second condition is not satisfied.

[bastihav]

Suggested change

	After perfoming the constant propagation, the statement<code>b = use(a)</code>can be replace with<code>b = use(const)</code>iff<code>a</code>is not redefined on all the paths from<code>a = const</code>to<code>b = use(a)</code>.
	After perfoming the constant propagation, the statement<code>b = use(a)</code>can be replaced with<code>b = use(const)</code>iff<code>a</code>is not redefined on any of the paths from<code>a = const</code>to<code>b = use(a)</code>.

[bastihav]

Suggested change

Therefore, the first used<code>l1</code>in the second example can be replace with the constant<code>1</code>, but the second used<code>l1</code>cannot be replaced with the constant<code>2</code>, because<code>l1</code>is redefined on the path from<code>l1 = 2</code>to<code>l4 = use(l1)</code>. However, it can replaced with local variable<code>l2</code>, because the both conditions of copy propagation are met.

Therefore, the first used<code>l1</code>in the second example can be replaced with the constant<code>1</code>, but the second used<code>l1</code>cannot be replaced with the constant<code>2</code>, because<code>l1</code>is redefined on the path from<code>l1 = 2</code>to<code>l4 = use(l1)</code>. However, it can replaced with local variable<code>l2</code>, because the both conditions of copy propagation are met.

[bastihav]

Suggested change

In the given example, the StaticSingleAssignmentFormer assigns to a new local variable for each<code>IdentityStmt</code>and<code>AssignStmt</code>. And each use uses the local variable which is most recently defined. Sometimes, it is impossible to determine the most recently defined local variable for a use in a join block. In this case, the StaticSingleAssignmentFormer will insert a<code>PhiStmt</code>in the front of the join block to merge all most recently defined local variables and assign them a new local variable.

In the given example, the StaticSingleAssignmentFormer assigns each<code>IdentityStmt</code>and<code>AssignStmt</code>to a new local variable. And each use uses the local variable which is most recently defined. Sometimes, it is impossible to determine the most recently defined local variable for a use in a join block. In this case, the StaticSingleAssignmentFormer will insert a<code>PhiStmt</code>in the front of the join block to merge all most recently defined local variables and assign them a new local variable.