Hi Aiden, Thanks for looking into this. When I get a chance I'm going to try to play around with opt passes to see what sort of impact on JS size they have.
As for your run through, g represents a scratch variable for the stack top, so we're allocating 32 bytes. This is less to do with the variables themselves, and more about the stack space. several of the stack spots don't have overlapping lifetimes, so theoretically we could allocate fewer stack variables. The code is a simple function I used to talk about Emscripten internally at work. Something easy to follow but using embind and showing off that C++ optimizations can impact the generated JS. On Friday, March 4, 2016 at 4:28:00 PM UTC-8, Aidan Hobson Sayers wrote: > > @Alon > > I've not seen anything in the asm.js optimizer to suggest it cares about > stack sizes - I assume you're talking about LLVM? > > @Charles > > I took another look at this. First off, the optimizations suggested in my > previous e-mail are incorrect - because I ran 'registerizeHarder' on asm.js > that already had 'last' applied to it (which strips some type annotations > used by the optimizer), the optimizer assumed all the variables were the > same type which causes invalid optimizations. > > So, to now answer your question on registerizeHarder used by -Oz: the > short answer is that the optimization looks nontrivial and I'm not sure how > helpful it'd be. The long answer is below. > > `p` and `q` weren't combined because registerizeHarder is mainly > interested in inter-basic-block variable flow (i.e. seeing how variables > are used between basic blocks in code with branches) - your example is a > single basic block. The intra-basic-block analysis > <https://github.com/kripken/emscripten/blob/07b87426f898d6e9c677db291d9088c839197291/tools/optimizer/optimizer.cpp#L3039> > looks > for assignments as they 'kill' variables, allowing for reuse. Your example > is interesting because there are no assignments, just two variables which > do not overlap in their usage. Here's a more minimal example that > registerizeHarder will also not bother with: > > ``` > function a() { > var i1 = 0, i2 = 0; > i1 = 4|0; > i2 = 5|0; > b(i1); > b(i2); > } > ``` > > The tricky thing about optimizing is you need to track how the variables > are defined - the example above is pretty easy, no variable names are > involved in the initialisation of i2 so you can freely move it around > (specifically, move it after `b(i1)` and make it `i1 = 5|0;`). But in your > case, `q` is initialised in terms of `g`. So to move the initialisation of > `q` after the use of `p` (in order to re-use the `p` register) we'd have to > verify that 1) `g` is a local (easy), 2) `g` is not modified between the > current initialisation location and the target initialisation location > (less easy). > > Extending this to work across basic blocks (e.g. if `a` and `b` are used > in disjoint sets of basic blocks with strict order) gets even harder. It's > still possible though! > > I don't know what others think, but I vaguely feel that this optimisation > wouldn't be a big wine...but the only way to check would be to measure. Out > of curiosity, how did you come across this? It's a good spot! > > On 29 February 2016 at 19:51, Alon Zakai <[email protected] <javascript:>> > wrote: > >> Looks like in -O3 16 bytes of stack are allocated, compared with 32 for >> -Os and -Oz. So it looks like what you want happens in some optimization >> modes. -Os and -Oz focus on code size, so perhaps they just don't care >> about stack optimizations like these? >> >> >> >> On Wed, Feb 24, 2016 at 3:25 PM, Charles Vaughn <[email protected] >> <javascript:>> wrote: >> >>> Looking at a simple test example disassembly to demonstrate Emscripten, >>> I noticed a potential optimization opportunity. >>> >>> See the gist here: >>> https://gist.github.com/hackcasual/e0262caec12bd60b2fe1 >>> C++ is in a comment on top, compiled with -Oz >>> >>> For example, q and p are pointers allocated on the stack, however as >>> their lifetimes don't overlap couldn't p be dropped and just q used? >>> Similar to what the registerization pass does. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Aidan > > Currently co-authoring a book on Docker > <http://manning.com/miell/?a_aid=aidanhs&a_bid=e0d48f62> - get 39% off > with the code 39miell > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
