I add the following expression in InstCodeSelector::addElemIndex():
Opnd* current_buffer = irManager.newImmOpnd(typeManager.getInt32Type(),
(unsigned)¤t_obj_acc_record_pointer);
Opnd * Ip_Opnd =
irManager.newMemOpndAutoKind(typeManager.getPrimitiveType(Type::UInt32),
current_buffer, irManager.newImmOpnd(typeManager.getInt32Type(), 8));
copyOpnd(Ip_Opnd, irManager.newImmOpnd(typeManager.getInt32Type(),
0x19820514));
It seems that the constraints of the Opnds are wrong. Is it?
current_obj_acc_record_pointer points to a buffer of type obj_acc_record
typedef struct {
uint32 base;
uint32 offset;
uint32 ip;
uint32 other_info;
}obj_acc_record;
2007/1/25, Mikhail Fursov <[EMAIL PROTECTED]>:
On 1/25/07, zouqiong <[EMAIL PROTECTED]> wrote:
>
> >
> > You are right. If the only change you do is a new extra call in
> translator
> > it will limit optimizations. The best place to add tracing calls could
> be
> > hir2lir conversion, after all HLO optimizations were finished, but in
> this
> > case your helper can't be inlined.
> >
> > If you want your helper to be inlined try to add additional 'getfield'
> > instrumentation pass into the middle of optimizer's pipeline: after
> > inliner
> > and memopt.
> >
> > --
> > Mikhail Fursov
> >
> > I think I can directly instrument code to trace the object, not by
> instrumenting call instruction.
>
> What do you mean by HLO optimization? I instrument at Code Selector Pass
> and
> now I can trace getfield and aaload.
Jitrino's code generation pipeline can be splitted into 2 parts: HLO and
CG
(codegen)
HLO part performs HIR optimizations/transformations
CG part performs LIR optimizations/transformations
LIR optimizations are very limited and very platform specific.
For example, inlining of Java methods is not platform specific, so this is
HLO optimization.
If you put your helper into Code Selector Pass (which is also called
'hir2lir') it's OK.
The only drawback I see here: your tracking call will never be inlined.
--
Mikhail Fursov
--
Best Regards,
Qiong,Zou