Ah yes, I see. I saw your mention of 'registerization' and came at it from the point of view of the asm.js optimizer, which mostly treats indexing access as a black box so I focused on register elimination.
I guess you'd want to look at LLVM optimisations for actual stack optimisation (per Alon's more succinct message), but I'm more hazy on that. On 7 March 2016 at 04:49, Charles Vaughn <[email protected]> wrote: > 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]> 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. > -- 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.
