948853 - Refactor register allocation a little bit

Status: RESOLVED DUPLICATE of bug 950703

(Core :: JavaScript Engine: JIT, defect)

Description

[haitao]

Attachment: 0001-Introduce-registerKind.patch

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Comment 1

[haitao]

Basically I combined all the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=947711 and rebased with inbound. The registerKind is introduced to prepare for allocating registers for SIMD. I wish we could land this part first before adding SIMD registers.

The X64 port is ready, could you let me know how to compile x86 and ARM in a X64 machine?

Comparing with the refactoring for V8 (https://codereview.chromium.org/24438006/), it seems that we modified too many places to achieve this.

Comment 2

[haitao]

Is it possible to use LAllocation and remove the MoveOperand in MoveResolver.h? For the parallel moves, the operands should be register, stack slots or constants, they all could be represented by LAllocation.

And why we need Move::Kind in MoveResolver.h?

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to haitao from comment #2)
> Is it possible to use LAllocation and remove the MoveOperand in
> MoveResolver.h? For the parallel moves, the operands should be register,
> stack slots or constants, they all could be represented by LAllocation.

LAllocation is the abstraction used by the Lowering and the register allocator.  The Move resolver is also used for handling the arguments in callVM.  This is bogus, the move resolver should never have been used for this kind of usage, but it the mean time we have to handle it.

> And why we need Move::Kind in MoveResolver.h?

We need the Kind enum to refer how are transfered the arguments while doing a CallVM.  The kind is used to say that we are taking a pointer to the element which is stored on the stack, or that we copy the value, and what kind of value it is.

Comment 4

[haitao]

> LAllocation is the abstraction used by the Lowering and the register
> allocator.  The Move resolver is also used for handling the arguments in
> callVM.  This is bogus, the move resolver should never have been used for
> this kind of usage, but it the mean time we have to handle it.

Why do we need MoveResolver for handling arguments? Are them parallel moves? I image we could store each parameter into the corresponding stack slot sequentially.

> We need the Kind enum to refer how are transfered the arguments while doing
> a CallVM.  The kind is used to say that we are taking a pointer to the
> element which is stored on the stack, or that we copy the value, and what
> kind of value it is.

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to haitao from comment #4)
> > LAllocation is the abstraction used by the Lowering and the register
> > allocator.  The Move resolver is also used for handling the arguments in
> > callVM.  This is bogus, the move resolver should never have been used for
> > this kind of usage, but it the mean time we have to handle it.
> 
> Why do we need MoveResolver for handling arguments? Are them parallel moves?
> I image we could store each parameter into the corresponding stack slot
> sequentially.

If they were all stack slots yes.  But x64 and ARM are are also using register as part of their call convention.  Thus the callWithABI is using the MoveResolver to solve cyclic moves when for example two arguments are swapped.

To be honest I think this is a dirty solution, and I think we should probably remove this MoveResolver from the callWithABI and just assert that we are not using registers which might be interpreted as a register used for a lower argument.  I will open a bug for it …