Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Compiler: Optimizing
-
Labels:None
Description
Currently we can eliminate the throwable constructed in the following form:
int foo() {
int x = 0;
try {
throw new Throwable();
} catch (Throwable t) {
x = 2;
}
}
but we can't handle the following:
static boolean z;
int foo() {
int x = 0;
try {
if (z) {
throw new Throwable();
} else { throw new Throwable(); } }
} catch (Throwable t) { x = 2; } }
}
this is because there are two possible sets of the exception object and therefore no clear dominator. We should do better analysis to remove the redundant throwable construction.
r14060 allows elimination of the Throwable in the situation above. As of r14060 we eliminate set caught exception instructions if there are no get caught exception instructions that can read them. It would be better if we could eliminate the sets if there are no reachable (dominated) gets. It's not safe to remove set->gets with moves unless there are no PEIs that could also do the set ie:
try {
call ... // some PEI
throw new Throwable();
} catch (Throwable t) {
... = t; // use of t
}
we can't make it:
try {
call ... // some PEI
x = new Throwable();
} catch (Throwable t) {
t = x;
... = t; // use of t
}
as the PEI call could also have been setting t.
We could extend the current scheme to remember when sets are eliminated from a method, when compiling that method in the future we could avoid generating the sets. This may get around the problem that the simple optimization is likely to not optimize the code when we do a lot of inlining and have a number of unrelated try-catch blocks.