Yes, V8's optimizing compiler performs "Common Subexpression Elimination".
The number of available registers does matter a lot. We've seen cases where
recomputing values when they are needed (somewhat counter-intuitively)
yielded better performance than computing them once and keeping them
around. In particular, loading a property from an object is not necessarily
more expensive than loading it from a spill slot. So when a given
compiler's output doesn't match your intuition, it's hard to be sure
whether that indicates untapped optimization potential, or whether it
actually turns out to be faster that way.
On Wed, Mar 25, 2020 at 6:47 AM J Decker <d3c...@gmail.com> wrote:
> Say I have this snippet of code....
>
> {
> var no_overlap = true;//( pd.algorithm == match_types.TwoGroupsNoOver )
> //|| ( pd.algorithm == match_types.TwoGroupsPrimeNoOver );
> //var prime = ( pd.algorithm == match_types.TwoGroupsPrime )
> // || ( pd.algorithm == match_types.TwoGroupsPrimeNoOver );
> var g;
> var masks = []
> var index = [];
> var n = 0;
> var m = 0;
>
> for( g = 0; g < pd.groups.length; g++ ) {
> simple_masks.push( ExpandMods( pd.groups[g].mode_mod, pd.groups[g].masks )
> )
> index.push(0);
> }
> do {
> var composite = 0;
> for( g = 0; g < pd.groups.length; g++ ) {
> masks[g] = simple_masks[g][index[g]];
> if( no_overlap )
> if( composite & masks[g] ) {
> break;
> }
> composite |= masks[g];
> }
> if( g < pd.groups.length ) {
> g++; // add 1 to g... so 'this' gets incremented
> // this faulted, so next iterate.
> for( var h = g; h < pd.groups.length; h++ ){
> index[h] = 0; // reset all the following counters
> }
> }
> else
> composite_masks.push(composite);
> // iterate combination set.
> index[g-1]++;
> while( g > 0 && ( index[g-1] >= simple_masks[g-1].length ) ) {
> if( g > 1 ) // don't reset 0.
> index[g-1] = 0;
> if( --g > 0 )
> index[g-1]++;
> }
> if( !g ){
> if( index[0] >= simple_masks[0].length )
> break;
> }
> }while(1);
> }
>
>
> This is all algorithmic; no expression calls a function, so a lot of
> things should be easiliy identifiable as unchanging.
>
> pd.groups.length
>
> for instance comes from 'pd.groups' which will never change during the
> duration of the above code, and that array within it also would not change,
> would the length for that be read once at the start?
> I've seen compiled code from C (where many compilers apparently assume
> that everything is at least somewhat volatile (apparently) and reload
> values of partial expressions even though that same value was just computed
> in the previous section. Especially where the number of available scratch
> registers is plentiful (as opposed to only 4-6) ?
>
> I would hope that I could write visually appealing code like the above and
> have the guts of the actual code generation do all the clever work; maybe
> it is a lot of work to do a pattern match in an AST and find all
> sub-expressions that are exactly the same to coalesce into a single
> access...
>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/CAKSzg3Q4TSgk2A2wW-rkZJOTkABz6%3DQqkPxAdp9__3kT%2BPHN7g%40mail.gmail.com.
