LIRGenerator.emitMove()

[Andrew Haley]

Hi,

On 27/10/16 16:53, Roland Schatz wrote:

> On 10/27/2016 05:29 PM, Andrew Haley wrote:
>>      @Override
>>      public Variable emitMove(Value input) {
>>          assert !(input instanceof Variable) : "Creating a copy of a variable via this method is not supported (and potentially a bug): " + input;
>>          Variable result = newVariable(input.getValueKind());
>>          emitMove(result, input);
>>          return result;
>>      }
>>
>> So how am I supposed to copy a variable?
> In Graal LIR, there are no destructive updates, so there should never be 
> a need to copy a variable (it's basically SSA-form before register 
> allocation).

OK, so this is a bug in the AArch64 port.  Got it.

> If you want to "modify" a variable (e.g. two-operand assembler 
> instruction), you should still create a new variable for the result, and 
> put a HINT on the LIR instruction that does the modification. The 
> register allocator will try to allocate the input and the result to the 
> same register. If it's not possible to do so (e.g. because the input has 
> another use later), you have to do the move from the input register to 
> the result register manually.
> 
> See for example the class AMD64Binary.TwoOp. That's used for 
> implementing the x86 two-operand arithmetic instructions that have a 
> common register for the result and the first input.
> (the "AMD64Move.move(crb, masm, result, x);" call emits a MOV 
> instruction if `result` and `x` are different registers, and nothing if 
> they are the same)

OK.  I'll look some more, thanks.

Andrew.