1009304 - Redundant instructions after LICM

Status: RESOLVED DUPLICATE of bug 831773

(Core :: JavaScript Engine: JIT, enhancement)

Description

[Dan Gohman [:sunfish]]

Attachment: rerun-gvn-after-licm.patch

LICM can hoist congruent values out of loops from places inside the loop where none of them are dominating each other (so GVN can't eliminate them) all into the preheader where they are all together.

For example, in this code:

  for (...) {
     if (x) {
        ... = a + b;
     }
     if (y) {
        ... = a + b;
     }
  }

GVN can't eliminate either copy of "a + b" because neither dominates the other. But if LICM hoists them:

        ... = a + b;
        ... = a + b;
  for (...) {
     if (x) {
     }
     if (y) {
     }
  }

Now they could be easily eliminated.

The attached experiment patch just re-runs GVN (and UCE) after LICM. It eliminates about 4% of the final number of instructions in sqlite3 VdbeExec. It doesn't appear to have a significant performance impact in that benchmark though, probably because most of the redundant instructions are outside of the loop by that time.

Another possible approach is to have LICM keep track of redundant values as it hoists.

Comment 1

[Alon Zakai (:azakai)]

I don't see a performance change on the benchmark suite either. But the code savings here *have* to help in some cases. Perhaps it would matter more on ARM?

Comment 2

[Jan de Mooij [:jandem]]

I've also seen this on (non-Emscripten) benchmarks, would be nice to have this fixed.

Maybe LICM could have an heuristic to decide whether it's worth re-running GVN? Ideally we'd run the new, faster GVN implementation you're working on :)

Comment 3

[Guilherme Lima]

Bug 831773?

Comment 4

[Dan Gohman [:sunfish]]

Indeed. Thanks!