Closed Bug 1270156 Opened 9 years ago Closed 8 months ago

Move recover instructions forward

Categories

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

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: h4writer, Unassigned)

References

(Blocks 1 open bug)

Details

In the last few months a lot of fuzzbug were attributed to recover instructions. Most reported fuzzbugs have been patched up, but there seem to be some structural issues. As a result we till expect new issues when wanting to use this for more. There has been some discussion about the effort the benefits/tradeoffs and we would like to keep this and improve it so we can use it in even more cases. Some of the issues and partial conclusions are in https://public.etherpad-mozilla.org/p/recoverins. Recover instructions have some constraints: 1) Fallible instructions need to add guards when wanting to put that instruction into the recover path. 2) Recover instructions need to behave similar to their MIR instruction This bug will be a meta bug to move this forward. My current approach is: 1) Add a virtual function to add guards upon putting an instruction on recover path. 2) Adjust the MBinaryArith recover instructions to truncate if they are truncated. 3) Let truncation pass opt out of adding guards. 4) Revert bug 1246200. Since that should now not fail (and confirm) 5) Add RPhi for non loop phi's
Has anything happened here, or is likely to happen in the foreseeable future?
Flags: needinfo?(hv1989)
Priority: -- → P5
Flags: needinfo?(hv1989)
Severity: normal → S3

Nicolas: As the resident expert on recover, I'll let you decide on whether this bug actually contains anything actionable or worth keeping.

Blocks: sm-jits
Flags: needinfo?(nicolas.b.pierron)

The premise of this bug is wrong.

(In reply to Hannes Verschore [:h4writer] from comment #0)

Recover instructions have some constraints:
2) Recover instructions need to behave similar to their MIR instruction

Recover instructions are not meant to emulate MIR instructions, they are meant to emulate the parts which are missing from Ion to go back to the interpreter. The confusion comes from the fact that some Recover Instruction do not have any sensible meaning out-side of Ion, such as RObjectState.

Most Recover instruction are meant to handle all cases like the interpreter does.

Truncation should not be converted in Recover Instruction lingua, as Ion truncation is a conclusion that can only be proven in the scope known by IonMonkey, and it cannot safely be extended to Recover Instruction, which by definition are falling out of the known scope of IonMonkey.

Status: NEW → RESOLVED
Closed: 8 months ago
Flags: needinfo?(nicolas.b.pierron)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.