Yes, I meant LLVM.

On Fri, Mar 4, 2016 at 4:27 PM, Aidan Hobson Sayers <[email protected]>
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.
>

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

Reply via email to