Can we remove constant folding from the frontend now (with JM+TI)?

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: cdleary, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

As I understanding it, JM+TI does constant folding on an SSA representation of the method.

We keep source notes to reconstruct folded source, which is approximately the size of the original bytecode anyway.

Removing constant folding from the frontend would be a nice complexity reduction, avoids a whole AST traversal, and I think js_FoldConstants floats around in the crash stats.

Brian, any JM+TI reason this wouldn't work?
As I understand it, even!
TI is not enabled on chrome -- I think js_FoldConstants() can only go away alongside the tracer.
As we just discovered, it looks like javascript.options.methodjit.chrome is true in nightly, which makes comment 2 seem like it might be outdated info. Brian?
TI is currently disabled for chrome. There's no pref but this is hardcoded in nsJSEnvironment.cpp
TI aggressively discards information in non-compileAndGo code for simplicity, and will not provide much speedup over the baseline mjit.  Rather than improve this I'd rather wait for compartment-per-global to make all code compileAndGo.
Also, njn has talked about re-disabling methodjit for chrome due to memory use regressions. See bug 646312 comment 24. Though if I understand bug 671759 correctly, wouldn't it mitigate that regression?
(In reply to Ryan VanderMeulen from comment #6)
> Also, njn has talked about re-disabling methodjit for chrome due to memory
> use regressions. See bug 646312 comment 24. Though if I understand bug
> 671759 correctly, wouldn't it mitigate that regression?

With bug 685358 (on the JM branch, should merge to m-c in the next few days), we'll be discarding chrome mjit code as aggressively as content mjit code.  This should reduce or eliminate that regression.
Also, JM+TI does not do any extra constant folding vs. JM, which does its own folding.  I think that folding is something which should only happen in one place, and the compiler is the better place (more information available).
(In reply to Brian Hackett from comment #8)
> I think that folding is something which should only happen in
> one place, and the compiler is the better place (more information available).

I don't remember JM doing string literal folding, which may not be too much fun to implement if you have to track it via the FrameState.  With this plus comment 5, I think we'll WONTFIX this for JM+TI.

I'll WONTFIX for now and we can revisit when IonMonkey is more complete.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.