@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]> 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]> 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]. >> 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]. > 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.
