Reduce minified code size to be closer to closure

[kripken]

I did some quick tests to see why closure emits smaller minified code than us.

First main issue is we do not currently run uglify's squeeze optimizations (return uglify.uglify.ast_squeeze(ast)), which are supposed to be competitive with closure. This could reduce code quite a bit. It is great on small testcases, but infinite loops on larger ones. Perhaps upgrading our uglify would fix that, or we could investigate what's going on.

We would only enable optimizations consistent with asm.js though. But most should be. I suppose another option is to do the same with closure, but that seems much harder.

I also looked at some source samples to see why closure is better. Some observations:

1. We should convert { x; y; z; } into (x, y, z). Often the parens can be dropped, and it enables more optimizations (see next).
2. if (q) (x, y, z) [else (a, b, c)] => q ? (x, y, z) : [(a, b, c) or 0]. This seems like a big optimization. It depends on the previous one. Note that this can casecade, so it needs to be done in a post-visitor.
3. We could drop curly braces in switch cases and default.
4. while(1) ==> for(;;), but need to measure perf.
5. if (x) a = y else a = z => a = x ? y : z
6. x + (-y) => x - y. Closure doesn't do that actually, but we should!
7. x; for (;;) => for (x;;), saves one ;.

[kripken]

cc @chadaustin

[keheliya]

Hi @kripken
I'd like to look into why uglify's squeeze optimizations are not working for larger programs. Can you point me to example C/C++ programs or LLVM IR that can lead to above unoptimized code? eg: case 6 (x + (-y))

[kripken]

I don't know offhand, but it should be almost all the time. Just any C code doing x - 5 will likely end up x + -5, I think. I noticed it just by visually scanning one of the things in the test suite, i don't remember which though.

[waywardmonkeys]

What's a good first step (or 2) to working on this?

[kripken]

I would just emit code as minified but with whitespace (-g1) in -O3 and in -O3 --closure 2 modes. The latter has full closure opts applied. Then can try to find patterns that they do better. Might be best to limit closure to simple opts, not advanced (can hack that in tools/shared.py).

[kripken]

-g2 might be easier with closure simple.

[kripken]

#2801 is a concrete example of something that would help here.

[gagern]

Perhaps upgrading our uglify would fix that…

Regarding that, see #3523

[nazar-pc]

Is this still relevant?

[kripken]

I think we can close this. The asm.js minifier has been improved over time, and meanwhile anyhow our focus is shifting more to wasm. For the non-asm.js code that still matters in wasm, I don't think it makes sense to compete with closure, we should just use it.