harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [Drlvm][Opt]How to avoid instrumentation's effect on Reg-Allocation?
Date Fri, 09 Feb 2007 16:08:36 GMT
On 2/9/07, zouqiong <ustczz@gmail.com> wrote:
> In fact, performance is not my problem.
> I just want my instrumentation won't affect the code.
> It means that if I remove the instrumentation, the code can still work
> correctly.
>       mov    %ebp, eax
>       add    0xc, eax
> //start of my instrumentation
>       mov    $0xe1f0f4,%ebx
>       mov    (%ebx),%edx
>       mov    $0xe1f0f4,%ebx
>       subl   $0x10,(%ebx)
>       mov    %eax,(%edx)
>       mov    0x8(%esp),%eax
>       mov    %eax,0x4(%edx)
>       movl   $0x9a0000,0x8(%edx)
> //end of my instrumentation
>       mov    0xc(%ebp,%eax,4),%ebp
> if the instrumentation is removed, the code becomes:
>       mov    %ebp, eax
>       add    0xc, eax
>       mov    0xc(%ebp,%eax,4),%ebp
> because the eax is updated in my instrumentation, so without my
> instrumentation, the code can't work.

the answer is: code modification after register allocation is not an easy
task. You have to take into account a lot of things to remove a region with
your code. In your example EAX is used as intermediate var. Is it really
part of your code? Did you add these stack operations or it was another CG
LIR transformation pass who did?
+ Why do you need remove your instrumentation? Once you add it to LIR
operands/insts can be moved and replaced by another insts. Instead of
removing your part of code it's better avoid adding it.

This is the first thing. I still have another problem. It's odd.
> Opnd* addrOpnd = irManager.newImmOpnd(typeManager.getUnmanagedPtrType(
> typeManager.getUIntPtrType()),
> (POINTER_SIZE_INT)&current_obj_acc_record_pointer);
> Opnd* memOpnd =
> irManager.newMemOpnd(typeManager.getUIntPtrType(),MemOpndKind_Heap,
> addrOpnd, NULL, NULL, NULL);
> Opnd* AddrOpnd = irManager.newRegOpnd(typeManager.getUnmanagedPtrType(
> typeManager.getUIntPtrType()), RegName_EDX);
> appendInsts(irManager.newInst(Mnemonic_SUB,memOpnd, irManager.newImmOpnd(
> typeManager.getUInt32Type(), 16)));
> appendInsts(irManager.newCopyPseudoInst(Mnemonic_MOV,AddrOpnd,
> irManager.newMemOpnd(typeManager.getUIntPtrType(),
>                                         MemOpndKind_Heap, addrOpnd, NULL,
> NULL, NULL)));
> The code generated is:
>       mov    $0xe1f0f4,%ebx
>       mov    (%ebx),%edx
>        mov    $0xe1f0f4,%ebx
>       subl   $0x10,(%ebx)
> I don't know why the ebx is assigned with $0xe1f0f4 twice ? It's
> redundant.

Creating opnd you do not add it to LIR. You do add it to LIR when you add
insts with your opnd.
You have 2 insts here: MOV and SUB which manipulates with an immediate
'&current_obj_acc_record_pointer' value and use 2 different mem-opnds.
So it's OK that you have 2 movs. This is a construction of 2 different
mem-opds and is a target for peephole optimization we do not have today :)

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message