Use const in JS library code and enable Terser reduce_vars/unused

[sbc100]

Enable reduce_vars and unused in Terser --compress (added in
#27926) in tools/acorn-optimizer.mjs.

This inlines const values into their expression uses and drops the
resulting unused local const declarations (along with unused function
parameters and single-use inner functions) in optimized builds that do
not run Closure Compiler.

This allows us to use const in JS library code without paying a code
size cost, while reducing total JS code size in
test_no_closure_code_size by 612 bytes.

Timing highlights (test/hello_world.c with -sINCLUDE_FULL_LIBRARY,
~247 KB minified JS):

• minify_sync with compress: {defaults: false, evaluate: true, keep_fargs: false}: 165.1 ms (250,514 B)
• minify_sync adding reduce_vars: true, unused: true: 224.3 ms
  (+59.2 ms, or +26.7 ms for unused and +28.8 ms for reduce_vars),
  saving ~3.2 KB (247,346 B).
• On a standard -O2 hello_world.c build (~8.4 KB JS), minify_sync
  goes from 3.9 ms to 6.2 ms (+2.3 ms), saving 96 B.

[sbc100]

Let me know if you would like me to land the pass first, before making the widespread usage withing the library files?

[kripken]

What is the codesize cost you are concerned about here - the const keyword itself, or something else?

[sbc100]

What is the codesize cost you are concerned about here - the const keyword itself, or something else?

There are two consts:

1. The const keyword is 2 bytes longer.
2. let and const declarations of block-scoped and so cannot be combined into a single function level declaration (unlike var). With var know that closure can combine all them into a jut one single var per function.

With this inlining pass we don't pay either of these costs!

[kripken]

I see, thanks.

Can we get both of those benefits by just renaming const to var? That seems simpler but maybe I'm missing something?

[sbc100]

I see, thanks.

Can we get both of those benefits by just renaming const to var? That seems simpler but maybe I'm missing something?

Maybe, that seems like a rather odd way to achieve the goal though. What is it about the inlining approach the you don't like?

[kripken]

Just the complexity. It has to consider scoping, and it is around 100 lines. I think const=>var would be almost a one-liner?

[sbc100]

One other motivation I should mention is that this is needed for another change I have in the pipeline: cd9fbb5

[kripken]

More generally, these passes are not simple to read or write, so fewer and simpler ones seems worthwhile to me.

[sbc100]

The other reason we cannot just do const -> var here is that we want users of -Oz and -Os to have not pay the cost of these variables at all. I.e. I want to be create to create new const XX = YY variables without having to worry about the codesize costs for non-closure users.

An alternative is that we could run a full terser minifier in these most? I think terser will do constant inlining by default.

[kripken]

I want to be create to create new const XX = YY variables without having to worry about the codesize costs for non-closure users.

Doesn't const=>var fix that? Or do you mean we'd need to also fuse together the original var and the former-const-but-now-var? edit: oh, I see, you mean adding more for code clarity, so we'd really need to fuse them all to save size

An alternative is that we could run a full terser minifier in these most? I think terser will do constant inlining by default.

Yeah, that sort of makes sense to me. I'd say that Acorn passes are necessary when we are doing something that depends on Emscripten semantics (like safe-heap rewrite or export parsing/removal in metadce). But it feels a little wrong to start to replicate standard compiler optimizations in Terser and Closure?

I'm not totally opposed to trivial ones, though. Especially if Terser is slow (but I didn't check if it is)

[sbc100]

I want to be create to create new const XX = YY variables without having to worry about the codesize costs for non-closure users.

Doesn't const=>var fix that? Or do you mean we'd need to also fuse together the original var and the former-const-but-now-var? edit: oh, I see, you mean adding more for code clarity, so we'd really need to fuse them all to save size

But I think we really want to fully inline these, not just fuse them.. so the cost of adding a new const XXX = YY; (rather then having YY just inline) drops to zero, even for non-closure users.

An alternative is that we could run a full terser minifier in these most? I think terser will do constant inlining by default.

Yeah, that sort of makes sense to me. I'd say that Acorn passes are necessary when we are doing something that depends on Emscripten semantics (like safe-heap rewrite or export parsing/removal in metadce). But it feels a little wrong to start to replicate standard compiler optimizations in Terser and Closure?

I'm not totally opposed to trivial ones, though. Especially if Terser is slow (but I didn't check if it is)

Ok, maybe I'll look into integrating terser for -O3 / -Oz and -Os users then? That would avoid the perenial question of "does the regress non-closure users".

[kripken]

I agree that running Terser makes sense. Seems better than working on our own JS opts. My only concern is if it makes compile times a lot slower (but hopefully not, or hopefully there is a flag to control how much it does?)

[sbc100]

I agree that running Terser makes sense. Seems better than working on our own JS opts. My only concern is if it makes compile times a lot slower (but hopefully not, or hopefully there is a flag to control how much it does?)

I imagine it would only be fore -O3/-Oz/-Os/etc users so they already have a slow link time IIUC. And yes I imagine you could disable it completely with --minify=0.

[sbc100]

OK, this change now just starts using JS const in more places, now that terser is run on -O2 and above.

[sbc100]

I think I might split out the terser config changes and land them first..