The backtracking allocator generates better code, so we should eventually start using it. There is only downside, it takes longer than LSRA to find a solution. For regular IonMonkey we are also looking to enable it. Though we can't by default since the increased compilation time results in being stuck in baseline longer. We have a burst of compilation requests at usecount 1000. Increasing the compilation time a bit, makes the last scheduled compile starting much later. Therefore we are looking to enable it as a second optimization level. For normal code it does see some decreases in performance (i.e. richards) that need to get sorted out, but looks promising. For asm.js style code it seems always an improvement to enable backtracking. Since we compile in parallel we loose less time and only during compilation (before running). I see an improvement of 45000 to 50000 on octane-zlib. @Luke: I know you carefully measured the compilation process for odinmonkey. Would it be terrible to increase compilation time for better code? And can you quantify how much of a decrease in compilation time would hurt us?
Created attachment 8391113 [details] [diff] [review] Use backtracking on AsmJS style code
According to sunfish bug 968931 is the only remaining known bug for backtracking. So we need to fix that first, before we can flip the switch. (From what I see it involves VMCalls, which I think is done differently on asm.js. So maybe we don't even have to fix it for asm.js release actually).
I've measured backtracking's effect on compile time several times and it's always been a tolerable increase so I'm in favor of enabling backtracking once the known bugs are fixed. There will almost certainly be bugs lurking that will be discovered by fuzzers or demos when asm.js is enabled so let's land this at the beginning of a release cycle (which is fortunately soon). Also, we should verify that the major demos aren't broken which I can do.
Comment on attachment 8391113 [details] [diff] [review] Use backtracking on AsmJS style code r+ with the above caveats
Comment on attachment 8391113 [details] [diff] [review] Use backtracking on AsmJS style code We want to land this as soon as possible. But it would be good to have some fuzzing on this patch, since it is a major change to use backtracking. Now if possible you can guide the fuzzers to only look at code that has "use asm"
Comment on attachment 8391113 [details] [diff] [review] Use backtracking on AsmJS style code Nothing found on one core on Linux, overnight.
Comment on attachment 8391113 [details] [diff] [review] Use backtracking on AsmJS style code I would have to setup a specific fuzzing environment to test this (ASM.js specifically), that would probably take a while and jsfunfuzz covers the ASM.js parts of the engine a lot better, so I'd say go ahead with gkw's feedback+ unless you think that's not sufficient :)
Thanks. I've just pushed. https://hg.mozilla.org/integration/mozilla-inbound/rev/bf4d2479f33e
Emscripten test suite looks ok, as well as a few hours of fuzzing.
That sounds quite technical to me but I understand if you want to highlight your work on performance in Firefox. Anyway, added in the release note for 31.