IA32: Small assembler tweak for divsd->mulsd sequence

IA32: Small assembler tweak for divsd->mulsd sequence

Committed: https://code.google.com/p/v8/source/detail?r=14225

[Zheng Liu, 2013-04-02 06:44:21]

X64 already had it because I accidentally included it in a previous code review
http://code.google.com/p/v8/source/detail?r=13289
(oops, sorry!)

This change is that for some processor, sequence like:
divsd XMM0, xmm?
(movaps XMM0, XMM0)
mulsd xmm? ,XMM0

Will prevent div and mul execute in parallel even if they are indepedent (e.g.
belong to two loop iterations)
Adding [*anymov* XMM0, XMM0] can workaround it.

I tested it on Nehalem/Westmere (e.g. i7-9**/8**, Xeon X56**)
Not sure about newer processors.


Case to reproduce:
~12% faster on affected processors

var darr1 = new Float64Array([0.5, 0.5]);
var darr2 = new Float64Array([0.5, 0.5]);

function fn1(a, b, n) {
    var c;
    for (var i = 0; i < n; i++)
       c = b[i&1] * (1 / a[i&1]);
}

fn1(darr1, darr2, 10);
fn1(darr1, darr2, 10);
%OptimizeFunctionOnNextCall(fn1);
var start = Date.now();
fn1(darr1, darr2, 1000*1000*100);
print(Date.now() - start);

[Yang, 2013-04-09 16:27:52]

On 2013/04/02 06:44:21, Zheng Liu wrote:
> X64 already had it because I accidentally included it in a previous code
review
> http://code.google.com/p/v8/source/detail?r=13289
> (oops, sorry!)
> 
> This change is that for some processor, sequence like:
> divsd XMM0, xmm?
> (movaps XMM0, XMM0)
> mulsd xmm? ,XMM0
> 
> Will prevent div and mul execute in parallel even if they are indepedent (e.g.
> belong to two loop iterations)
> Adding [*anymov* XMM0, XMM0] can workaround it.
> 
> I tested it on Nehalem/Westmere (e.g. i7-9**/8**, Xeon X56**)
> Not sure about newer processors.
> 
> 
> Case to reproduce:
> ~12% faster on affected processors
> 
> var darr1 = new Float64Array([0.5, 0.5]);
> var darr2 = new Float64Array([0.5, 0.5]);
> 
> function fn1(a, b, n) {
>     var c;
>     for (var i = 0; i < n; i++)
>        c = b[i&1] * (1 / a[i&1]);
> }
> 
> fn1(darr1, darr2, 10);
> fn1(darr1, darr2, 10);
> %OptimizeFunctionOnNextCall(fn1);
> var start = Date.now();
> fn1(darr1, darr2, 1000*1000*100);
> print(Date.now() - start);

Sorry that it took this long.

Could you add a comment to the inserted instruction (also on x64) so that it
makes some sense when somebody looks at the code later on and won't accidentally
remove it?

[Zheng Liu, 2013-04-11 10:38:30]

On 2013/04/09 16:27:52, Yang wrote:
> On 2013/04/02 06:44:21, Zheng Liu wrote:
> > X64 already had it because I accidentally included it in a previous code
> review
> > http://code.google.com/p/v8/source/detail?r=13289
> > (oops, sorry!)
> > 
> > This change is that for some processor, sequence like:
> > divsd XMM0, xmm?
> > (movaps XMM0, XMM0)
> > mulsd xmm? ,XMM0
> > 
> > Will prevent div and mul execute in parallel even if they are indepedent
(e.g.
> > belong to two loop iterations)
> > Adding [*anymov* XMM0, XMM0] can workaround it.
> > 
> > I tested it on Nehalem/Westmere (e.g. i7-9**/8**, Xeon X56**)
> > Not sure about newer processors.
> > 
> > 
> > Case to reproduce:
> > ~12% faster on affected processors
> > 
> > var darr1 = new Float64Array([0.5, 0.5]);
> > var darr2 = new Float64Array([0.5, 0.5]);
> > 
> > function fn1(a, b, n) {
> >     var c;
> >     for (var i = 0; i < n; i++)
> >        c = b[i&1] * (1 / a[i&1]);
> > }
> > 
> > fn1(darr1, darr2, 10);
> > fn1(darr1, darr2, 10);
> > %OptimizeFunctionOnNextCall(fn1);
> > var start = Date.now();
> > fn1(darr1, darr2, 1000*1000*100);
> > print(Date.now() - start);
> 
> Sorry that it took this long.
> 
> Could you add a comment to the inserted instruction (also on x64) so that it
> makes some sense when somebody looks at the code later on and won't
accidentally
> remove it?

Comments addressed.
Please take another look.

[Yang, 2013-04-11 10:40:51]

On 2013/04/11 10:38:30, Zheng Liu wrote:
> On 2013/04/09 16:27:52, Yang wrote:
> > On 2013/04/02 06:44:21, Zheng Liu wrote:
> > > X64 already had it because I accidentally included it in a previous code
> > review
> > > http://code.google.com/p/v8/source/detail?r=13289
> > > (oops, sorry!)
> > > 
> > > This change is that for some processor, sequence like:
> > > divsd XMM0, xmm?
> > > (movaps XMM0, XMM0)
> > > mulsd xmm? ,XMM0
> > > 
> > > Will prevent div and mul execute in parallel even if they are indepedent
> (e.g.
> > > belong to two loop iterations)
> > > Adding [*anymov* XMM0, XMM0] can workaround it.
> > > 
> > > I tested it on Nehalem/Westmere (e.g. i7-9**/8**, Xeon X56**)
> > > Not sure about newer processors.
> > > 
> > > 
> > > Case to reproduce:
> > > ~12% faster on affected processors
> > > 
> > > var darr1 = new Float64Array([0.5, 0.5]);
> > > var darr2 = new Float64Array([0.5, 0.5]);
> > > 
> > > function fn1(a, b, n) {
> > >     var c;
> > >     for (var i = 0; i < n; i++)
> > >        c = b[i&1] * (1 / a[i&1]);
> > > }
> > > 
> > > fn1(darr1, darr2, 10);
> > > fn1(darr1, darr2, 10);
> > > %OptimizeFunctionOnNextCall(fn1);
> > > var start = Date.now();
> > > fn1(darr1, darr2, 1000*1000*100);
> > > print(Date.now() - start);
> > 
> > Sorry that it took this long.
> > 
> > Could you add a comment to the inserted instruction (also on x64) so that it
> > makes some sense when somebody looks at the code later on and won't
> accidentally
> > remove it?
> 
> Comments addressed.
> Please take another look.

LGTM.

[Yang, 2013-04-11 10:49:54]

Committed patchset #2 manually as r14225.

[Yang, 2013-04-11 13:38:28]

On 2013/04/11 10:49:54, Yang wrote:
> Committed patchset #2 manually as r14225.

This patch seems to have regressed this small benchmark:
function benchmark() {
  var fp = 1.5;
  for (var i = 0; i < 10000; i++) {
    fp = -(fp * 2.1) / 2.1;
  }
}

var elapsed = 0;
var start = new Date();
for (var n = 0; elapsed < 2000; n++) {
  benchmark();
  elapsed = new Date() - start;
}

So apparently, when division follows after multiplication, this slows things
down. Would it be possible to do this smarter somehow, so that the move is only
inserted when mulsd follows divsd?

[Zheng Liu, 2013-04-12 11:36:28]

On 2013/04/11 13:38:28, Yang wrote:
> On 2013/04/11 10:49:54, Yang wrote:
> > Committed patchset #2 manually as r14225.
> 
> This patch seems to have regressed this small benchmark:
> function benchmark() {
>   var fp = 1.5;
>   for (var i = 0; i < 10000; i++) {
>     fp = -(fp * 2.1) / 2.1;
>   }
> }
> 
> var elapsed = 0;
> var start = new Date();
> for (var n = 0; elapsed < 2000; n++) {
>   benchmark();
>   elapsed = new Date() - start;
> }
> 
> So apparently, when division follows after multiplication, this slows things
> down. Would it be possible to do this smarter somehow, so that the move is
only
> inserted when mulsd follows divsd?

Could you please tell me on the CPU and how much the regression is?
I tested on Nehalem and didn't notice the regression.

Being smarter looks a bit difficult.
I tried to do it in patch set 3, but it is hackish and inefficient.