1564806 - Cranelift: Eager evaluation of conditions (short-circuiting)

Status: RESOLVED MOVED

(Core :: JavaScript: WebAssembly, enhancement, P3)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

Say you have a condition like if (a || (b && c)) in high-level code, compiled to wasm. I've seen the resulting assembly code in Cranelift:

• evaluate condition a.
• store flags into a register.
• evaluate condition b.
• store flags into a register.
• evaluate condition c.
• store flags and and them with the b register.
• or this with the a register.
• do an actual branch based on the contents of the a register.

(I'll post the actual assembly code if I stumble on it again.)

Instead, if b and c results are not reused later on, we could do something like this, by duplicating the branches:

• evaluate condition a
• conditional branch (goto branch if a is true)
• evaluate condition b
• conditional branch on inverted condition (skip if b is false)
• evaluate condition c
• conditional branch (goto branch if c is true)

This would require fewer live variables (good for regalloc!), and could enhance throughput.

(Ion used to do something like this for asm.js code when the ternary operator was used, but not in the general wasm case.)

Comment 1

[Lars T Hansen [:lth]]

Is this still a concern? Should we create a metabug that tracks optimizations Ion does that CL does not do? Should that metabug be here or attached to the CL repo somehow?

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

Still a concern, but Bugzilla is probably not the best place to track this. We'll open a new issue in Cranelift, or will use another meta bug for this purpose.

Comment 3

[Lars T Hansen [:lth]]

OK. What about bug 1539403, bug 1552739, bug 1552741, bug 1552743, bug 1564817, and bug 1650038, to mention just some. (There's also the "Cranelift: performance parity with Baldr on ..." cluster of bugs.)

I don't have very strong feelings here but imo it would be nice if all CL bugs / issues that were clearly internal to CL were moved to the CL repo, leaving CL issues that pertain to the quality of CL as perceived by Firefox users tracked here. There are dangers both ways, but not knowing in which tracker something is filed is bad, and it's good if anything that any CL dev can work on is visible through the CL tracker as a matter of policy.

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

I'll bring it up during a meeting we're having today; my preferred choice would be to put everything on a Github's issue, because we usually don't track so much things on Bugzilla these days.