You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by zouqiong <us...@gmail.com> on 2007/02/08 08:51:05 UTC
[Drlvm][Opt]How to avoid instrumentation's effect on Reg-Allocation?
Hi, guys,
I instrument during code selector pass, however, I find that my
instrmentation affects the register allocation. For example as follows:
mov %ebp, eax
add 0xc, eax
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)
mov 0xc(%ebp,%eax,4),%ebp
The code in yellow backgroud is my instrumentation. And we can see
that EAX is loaded from the stack in the instrumentation. It's bad.
I don't want my instrumentation doing it.
Can someone tell me how can i avoid it?
Thanks,
Qiong
--
Best Regards,
Qiong,Zou
Re: [Drlvm][Opt]How to avoid instrumentation's effect on Reg-Allocation?
Posted by Tim Ellison <t....@gmail.com>.
zouqiong wrote:
> The code in yellow backgroud...
...doesn't make it through to everyone, better to mark it explicitly
with chars
Regards,
Tim
Re: [Drlvm][Opt]How to avoid instrumentation's effect on Reg-Allocation?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 2/9/07, zouqiong <us...@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)¤t_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
'¤t_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
Re: [Drlvm][Opt]How to avoid instrumentation's effect on Reg-Allocation?
Posted by zouqiong <us...@gmail.com>.
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.
This is the first thing. I still have another problem. It's odd.
Opnd* addrOpnd = irManager.newImmOpnd(typeManager.getUnmanagedPtrType(
typeManager.getUIntPtrType()),
(POINTER_SIZE_INT)¤t_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.
Thanks,
Qiong
2007/2/8, Mikhail Fursov <mi...@gmail.com>:
>
> Zouqiong,
> If you do instrumentation in HIR you can't predict which registers will be
> used in CG.
> If you do instrumentation in LIR you can only assign predefined registers
> or
> constraints to your operands, but you can't affect register allocation for
> unassigned operands.
> So if you think that RegAlloc does a bad job for you, this is RegAlloc
> issue
> and must be fixed in RegAlloc.
>
> + Reg-allocator does change side-effects of your code. Loading EAX from a
> stack in your example can have only 1 drawback: performance problem. Is
> performance your problem here?
>
> On 2/8/07, zouqiong <us...@gmail.com> wrote:
> >
> > Hi, guys,
> > I instrument during code selector pass, however, I find that my
> > instrmentation affects the register allocation. For example as follows:
> >
> > mov %ebp, eax
> > add 0xc, eax
> >
> > 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)
> >
> > mov 0xc(%ebp,%eax,4),%ebp
> >
> > The code in yellow backgroud is my instrumentation. And we can see
> > that EAX is loaded from the stack in the instrumentation. It's bad.
> > I don't want my instrumentation doing it.
> > Can someone tell me how can i avoid it?
> >
> > Thanks,
> > Qiong
> >
> >
> > --
> > Best Regards,
> > Qiong,Zou
> >
>
>
>
> --
> Mikhail Fursov
>
--
Best Regards,
Qiong,Zou
Re: [Drlvm][Opt]How to avoid instrumentation's effect on Reg-Allocation?
Posted by Mikhail Fursov <mi...@gmail.com>.
Zouqiong,
If you do instrumentation in HIR you can't predict which registers will be
used in CG.
If you do instrumentation in LIR you can only assign predefined registers or
constraints to your operands, but you can't affect register allocation for
unassigned operands.
So if you think that RegAlloc does a bad job for you, this is RegAlloc issue
and must be fixed in RegAlloc.
+ Reg-allocator does change side-effects of your code. Loading EAX from a
stack in your example can have only 1 drawback: performance problem. Is
performance your problem here?
On 2/8/07, zouqiong <us...@gmail.com> wrote:
>
> Hi, guys,
> I instrument during code selector pass, however, I find that my
> instrmentation affects the register allocation. For example as follows:
>
> mov %ebp, eax
> add 0xc, eax
>
> 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)
>
> mov 0xc(%ebp,%eax,4),%ebp
>
> The code in yellow backgroud is my instrumentation. And we can see
> that EAX is loaded from the stack in the instrumentation. It's bad.
> I don't want my instrumentation doing it.
> Can someone tell me how can i avoid it?
>
> Thanks,
> Qiong
>
>
> --
> Best Regards,
> Qiong,Zou
>
--
Mikhail Fursov