In the following test case (using asm.js, thus the backtracking allocator), x is in a register (first operand of the sub) but also spilled into a stack slot (second operand of the sub) rather than another available register: function(){"use asm"; function g(x){x=x|0; return x-x|0;} return g} Backtracking: (output of IONFLAGS=regalloc) Block 0 [2,3 AsmJSParameter] [def v1 =rdi] [MoveGroup] [=rdi -> =rax] [=rdi -> stack:4] [4,5 SubI] [def v2 =rax] [use v1:r =rax] [use v1:r? stack:4] [6,7 AsmJSReturn] [use v2:rax =rax] LSRA uses an empty register: Block 0 [2,3 Label] [4,5 AsmJSParameter] [def v1 =rdi] [6,7 Nop] [MoveGroup] [=rdi -> =rax] [8,9 SubI] [def v2 =rax] [use v1:r =rax] [use v1:r? =rdi] [10,11 AsmJSReturn] [use v2:rax =rax]

While debugging unrelated register allocation issues, I happened to notice the cause of this bug. The non-fixed operand is not used-at-start, so it interferes with the output register. This is needed because it's sometimes necessary to copy the fixed operand into the output before reading the non-fixed operand, however in the case where the operands refer to the same register, it isn't needed. Attached is a patch which enables used-at-start in more places on x86.

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/3af9693b858d for jit test failures: https://tbpl.mozilla.org/php/getParsedLog.php?id=40604427&tree=Mozilla-Inbound

Re-landed with the TruncateDToInt32 and TruncateFToInt32 changes reverted, as they're not safe on 32-bit x86, since it uses a temporary register and the temporary is written to before the operand is read. https://hg.mozilla.org/integration/mozilla-inbound/rev/48d4b111a911