946422 - Empty loop not optimized away

Status: NEW

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

Description

[Boris Zbarsky [:bzbarsky]]

Consider this script:

 (function (count) {
    var start = new Date;
    for (var i = 0; i < count; ++i);
    var stop = new Date;
    print((stop - start) / 10000000 * 1e6);
  })(10000000); 

Here's what JIT inspector says we end up doing for this:

Block #3 -> #4 -> #5 :: 9998904 hits
[Label]
[InterruptCheckImplicit]
[OsiPoint]
[CompareAndBranch:lt]
cmpl       %eax, %edx
jge        ((731))
 
Block #4 -> #3 :: 9998903 hits
[Label]
[AddI]
addl       $0x1, %edx
[Goto]
jmp        ((753))
##link     ((753)) jumps to ((753))
 

Why can't we just compile this down to a single assignment (i = count) and move on?  At least in the case when count is an int32; if count is a double, then adding 1 at a time might never reach it, of course.

Comment 1

[Sean Stangl [:sstangl]]

Detecting the circumstances in which this optimization can be made will affect the compile time of all scripts. Are you claiming that this optimization is valuable unto itself, or are you thinking it would be a precursor to a more general optimization such as loop unrolling?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Outside of microbenchmark pissing contests, I expect this optimization is not valuable in itself.

I can't speak to whether you could build other optimizations on top of this.

As in, a "not worth it, wontfix" might well be the right response to this bug.

Comment 3

[Nicolas B. Pierron [:nbp]]

We can do this optimization if range analysis can deduce the outcome of every variable manipulated in the loop, and that the loop is not effectful.