Hi, sorry that it took me this long to answer. The third patch set is indeed too hackish. I guess the ideal way would be doing it in a prior compilation phase for peephole optimizations. Currently, no such phase exists. So I think the way it currently is is fine for now. We may revisit this later at some point.
Regards, Yang Yang Guo | Software Engineer | Google Germany GmbH | Dienerstr. 12, 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens On Fri, Apr 12, 2013 at 1:36 PM, <[email protected]> wrote: > 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. > > https://chromiumcodereview.**appspot.com/13447003/<https://chromiumcodereview.appspot.com/13447003/> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" 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/groups/opt_out.
