start function optimization

[blooddy]

function init():void {
}
init();

output

(module
 (type $v (func))
 (memory $0 1)
 (export "memory" (memory $0))
 (start $.start)
 (func $init (; 0 ;) (type $v)
  (nop)
 )
 (func $.start (; 1 ;) (type $v)
  (call $init)
 )
)

an unnecessary $.start function is created.
most likely this will automatically be corrected if you add inline function support (#12)

[dcodeIO]

Yeah, the start function is automatically generated from all the top level statements. Running Binaryen's inlining pass will most likely optimize this away.

Once this PR lands in Binaryen, asc can support different optimization levels like -O3 etc., which then include inlining.

[MaxGraey]

I think this can already be closed

[dcodeIO]

What' still happening, though, is that if the start function becomes empty after optimizations, it is not removed by the optimizer. Looks like:

  (func $start (type $v)
    nop
  )
  (start $start)

[MaxGraey]

Sorry. I checked in WebAssembly Studio and this true. But in Assembleash I use this config:

 module.runPasses([ "trap-mode-clamp" ]);
 module.setOptimizeLevel(3);
 module.setShrinkLevel(2);

And this inlined perfectly. You can check

[dcodeIO]

Just checked: Try to compile just ; (EmptyStatement, emulates the rest of the body being optimized away) - this results in the empty start function mentioned above.

[MaxGraey]

I try in my playground and this is result:

[dcodeIO]

I see, yeah, the inlining works, but the start function is still there, though it could be removed.

[MaxGraey]

But this is normal... or not? I thought start should be always present

[dcodeIO]

It is not required that it's there, so imho it should be removed. This is a Binaryen specific thing, of course.

[dcodeIO]

See: WebAssembly/binaryen#1449

[MaxGraey]

Cool!

[dcodeIO]

Alright, the last remaining bits should be fixed as well using latest Binaryen. Closing for good.