llvm dev - Jun 2006 - [LLVMdev] Mapping bytecode to X86

Thank you Chris. I will try to implement the TwoAddress pass to run on
machine code. Why it has not been originally implemented to run on
machine code? Is there anything that makes it troublesome after RA
has been performed? Could you tell me if the transformations below
are correct?

1) a := b op c    -->     a := b          -->     a := b
                          a := a op c             a := c

2) a := a op c    -->     a := c

3) a := b op a    -->     a := a op b     -->     a := b    (???)

What if the operation in (3) is non-commutative?

Thanks a lot,

Fernando
> On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote:
> > The problem is that, after the TwoAddressInstructionPass is used, the
> > code is no longer in SSA form, and my register allocator rely on
> > some SSA properties. I am using the Spiller in VirtRegMap.* to
generate
> > the code, but the incorrect mapping still happens when I invoke the
> > setReg() method directly on machine operands. Any of you guys has some
> > hints to help me to produce correct mapping without using the Two
> > address pass?
>
> You're missing one critical piece.  Currently, the register allocator
is
> in charge of removing one of the operands of a two address instruction.
> Whether you choose to use the two-address pass or not (your choice), you
> should make sure that the first two operands of the instructions are
> assigned to the same register, and then you delete one.  For example,
> before RA you might have:
>
> vreg1024 = ADDxxx vreg1025, 123
>
> after, you should have:
>
> ADDxxx EAX, 123
>
> Where the "EAX" operand is marked as a def&use operand.
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira
wrote:
> Thank you Chris. I will try to implement the TwoAddress pass to run on
> machine code. Why it has not been originally implemented to run on
> machine code?
I'm not sure what you mean.  It definitely does run on machine code.
> Is there anything that makes it troublesome after RA
> has been performed?
Do you specifically mean removing the extra operand?  One of my eventual 
goals is to eliminate this behavior of the register allocator.  I'd much 
rather have it leave the instructions as:

EAX = OP EAX, EDX

instead of forcing it to:

OP EAX [D&U] EDX
> Could you tell me if the transformations below
> are correct?
>
> 1) a := b op c    -->     a := b          -->     a := b
>                          a := a op c             a := c
Yes.
> 2) a := a op c    -->     a := c
Yes
> 3) a := b op a    -->     a := a op b     -->     a := b    (???)
No.
> What if the operation in (3) is non-commutative?
2-address instructions are only two-addressy in their first two operands. 
You can't join the first and third operand.

Note that the 2-addr pass does all of the above for you, but it does 
destroy SSA.

-Chris

> Thanks a lot,
>
> Fernando
>
>> On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote:
>>> The problem is that, after the TwoAddressInstructionPass is used,
the
>>> code is no longer in SSA form, and my register allocator rely on
>>> some SSA properties. I am using the Spiller in VirtRegMap.* to
generate
>>> the code, but the incorrect mapping still happens when I invoke the
>>> setReg() method directly on machine operands. Any of you guys has
some
>>> hints to help me to produce correct mapping without using the Two
>>> address pass?
>>
>> You're missing one critical piece.  Currently, the register
allocator is
>> in charge of removing one of the operands of a two address instruction.
>> Whether you choose to use the two-address pass or not (your choice),
you
>> should make sure that the first two operands of the instructions are
>> assigned to the same register, and then you delete one.  For example,
>> before RA you might have:
>>
>> vreg1024 = ADDxxx vreg1025, 123
>>
>> after, you should have:
>>
>> ADDxxx EAX, 123
>>
>> Where the "EAX" operand is marked as a def&use operand.
>>
>> -Chris
>>
>> --
>> http://nondot.org/sabre/
>> http://llvm.org/
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

> > Thank you Chris. I will try to implement the TwoAddress pass to run on
> > machine code. Why it has not been originally implemented to run on
> > machine code?
>
> I'm not sure what you mean.  It definitely does run on machine code.
I was thinking that it only transformed instructions with virtual
registers because of this code in the TwoAddressInstructionPass.cpp:

        unsigned regA = mi->getOperand(0).getReg();
        unsigned regB = mi->getOperand(1).getReg();

        assert(MRegisterInfo::isVirtualRegister(regA) &&
               MRegisterInfo::isVirtualRegister(regB) &&
               "cannot update physical register live information");

By machine code I meant code with virtual registers, instead of machine
(physical) registers; not the passes on machine functions/machine basic
blocks.

Fernando