|
[
Permlink
| « Hide
]
David Grove added a comment - 30/Jul/08 07:35 AM
IR dump (it was truncated in the sanity report).
r14913 cleaned up the CFG construction in Inliner when the failedblock contains an OSR_YIELDPOINT. If my theory that the bad move instruction was introduced by BC2IR rectifying it's state at the downstream merge from the OSR_YIELDPOINT, then this should fix the bad IR. It also had the side benefit of speeding up antlr and bloat by 5%
Leaving open to monitor for a week to see if jbb2005 failure recurs after the fix. Will open a new feature for the longer term item of re-implementing context-sensitive call graph profiling. Problem was not fixed by r14913. http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/4927/regression_report
It's likely that r14923 improved the quality of the inlining decisions being made....but we still should think about context-sensitive profiling.
r14923 made the IR significantly simpler by avoiding bogus inlining, but we're still getting the bad IR failure. For example, see:
The thing that seems to be triggering the bug is that we do a guarded inline where the method body ends in an unconditional NPE because it is downstream of a statically failed checkcast. We're supposed to detect this and not link the (unreachable) epilogue block of the inlined method into the CFG, but that doesn't seem to be quite working.
Continuing to investigate... r14946 fixed a problem in how we were meeting together the results of multiple inlined targets. It's possible that this bug was then causing BC2IR to inject the unreachable block to rectify it's state downstream of the inlined code. Will monitor to see if failure continues to happen.
r14946 appeared to have changed this into a slightly different assertion failure in bc2ir.
vm internal error at: – Stack – not fixed by 14946/948. for example see:
http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/core-ppc64/5118/regression_report See: http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/core-ppc64/5150/prototype-opt/default/SPECjbb2005/SPECjbb2005
for the most recent failure the includes the full IR dump. The code that is raising the IR verification error is actually dead. (blocks containing the bad definition are not linked in the CFG).
I'm going to look a little more to see if I can figure out why they are even being generated in the first place, but I think there's an easy workaround which is to force the running of a r14957 pushed the initial HIR verification pass slightly later in the "Convert Bytecodes to HIR" block of phases. I believe this will result in the unreachable code being removed before we attempt to verify it.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
Problems with OSR guarded inlining of invokeinterface 
