Open Bug 1319747 Opened 8 years ago Updated 2 years ago

Make sure we don't try to create OSR entry point in unreachable code after try/catch

Categories

(Core :: JavaScript Engine: JIT, defect, P3)

defect

Tracking

()

People

(Reporter: h4writer, Unassigned)

References

Details

During the split I noticed that sometimes we tried to create an entry point to code that we decided was unreachable. (after try/catch with both having returns). We should investigate and fix that and make sure we can assert that again.
Depends on: 1310155
Putting P1 for now. I hope to do that soonish
Priority: -- → P1
This is the affected code: > for (;;) { > try { > throw 3; > } catch(e) { > break; > } > } > for (var i = 0; i < 15; i++) {} The issue is that we don't compile the catch block. As a result we don't know if it has cfg in it. Now we look at the the pc at the end of the catch to know if we can have code after the catch. But that code is never reached. The code is reached through the break. I looked at how we could make it smarter, without compiling the catch block. But I hit blockroads the whole time. I think the path forward here would be to compile the catch block and let prune branches do its job?
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.