No, I think this is actually a really obscure bug in the regalloc rules. If all the following conditions are met: - a MIR node gets two input operands that are the same - they are integer constants but importantly not subject to folding - the lowering uses useRegisterAtStart on *both* operands (but not useRegisterOrConstantAtStart) *and* uses defineReuseInput on the lhs then the MIR node gets two LIR nodes (for the constants) and the virtual registers get all messed up because some code gets it from the LIR node and some from the MIR node, and the MIR node has the vr of the input that's not being used.
Bug 1707774 Comment 28 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
No, I think this is actually a really obscure bug in the regalloc rules. If all the following conditions are met: - a MIR node gets two input operands that are the same MIR node - this shared input is an integer constant, so EmittedAtUses is true for it - the lowering calls useRegisterAtStart twice, one for "each" operand, lhs before rhs (but not useRegisterOrConstantAtStart) - the lowering uses defineReuseInput on the lhs then the MIR node gets two LIR nodes because the emitAtUses generates a new LIR node for each call to useRegisterAtStart, each with a vreg. The vreg is recorded in the MIR node after the LIR node has been created, by define(). But the MIR node can only hold one of the vregs and will hold only the rhs vreg (because the LIR node for the rhs was created last). Now the compiler can become confused because its vreg reflects the vreg of the rhs, not the vreg of the lhs.
No, I think this is actually a really obscure bug in how emitAtUses combines with reuseInput. If all the following conditions are met: - a MIR node gets two input operands that are the same MIR node - this shared input is an integer constant, so EmittedAtUses is true for it - the lowering calls useRegisterAtStart twice, one for "each" operand, lhs before rhs (but not useRegisterOrConstantAtStart) - the lowering uses defineReuseInput on the lhs then the MIR node gets two LIR nodes because the emitAtUses generates a new LIR node for each call to useRegisterAtStart, each with a vreg. The vreg is recorded in the MIR node after the LIR node has been created, by define(). But the MIR node can only hold one of the vregs and will hold only the rhs vreg (because the LIR node for the rhs was created last). Now the compiler can become confused because its vreg reflects the vreg of the rhs, not the vreg of the lhs.
No, I think this is actually a really obscure bug in how emitAtUses combines with reuseInput. If all the following conditions are met: - a MIR node gets two input operands that are the same MIR node - this shared input is an integer constant, so EmittedAtUses is true for it - the lowering calls useRegisterAtStart (not useRegisterOrConstantAtStart) twice, one for "each" operand, lhs before rhs - the lowering uses defineReuseInput on the lhs then the MIR node gets two LIR nodes because the emitAtUses generates a new LIR node for each call to useRegisterAtStart, each with a vreg. The vreg is recorded in the MIR node after the LIR node has been created, by define(). But the MIR node can only hold one of the vregs and will hold only the rhs vreg (because the LIR node for the rhs was created last). Now the compiler can become confused because its vreg reflects the vreg of the rhs, not the vreg of the lhs.