Re: [Tarantool-patches] [PATCH v4 1/2] core: introduce various platform metrics

[Igor Munkin <imun@tarantool.org>]

Sergey,

Thanks, this patch also LGTM.

On 08.10.20, Sergey Kaplun wrote:
> Igor,
> 

<snipped>

> > > > > +  emit_setgl(as, RID_RET+2, gc.cdatanum);
> > > > 
> > > > Well, I glanced a MIPS register-usage convention and AFAICS $4 register
> > > > (RID_RET + 2) is a general-purpose (i.e. doesn't store 0 or preserved by
> > > > kernel) caller-safe one. Ergo it should be allocated it in a proper way
> > > > from scratch set, shouldn't it?
> > > > 
> > > 
> > > AFAIK, $a0 - $a3 ($4 - $7) registers are arguments to functions - not
> > > preserved by subprograms.
> > 
> > Yes, but there is e.g. $8, that is temporary one, isn't it? Anyway, you
> 
> Yes, for example.
> Side note: We can omit the call to the register allocator, since these
> registers can change during the call, but in order not to be tied to ABI
> we can use a lightweight `ra_scratch`, indeed.

Agree here: you can pick any of caller-safe registers instead of
scratching it. All values contained in these registers should be
preserved prior to call, so nothing is broken in your previous version
(i.e. not a lucky coincidence). However, using explicit scratching here
looks at least more consistent to me.

> 
> > can't just pick the particular register, since it can be already
> > allocated by RA. So it *has* to be explicitly allocated to avoid data
> > clash on the trace. I strongly believe the reason you see no failure on
> > tests is simply a lucky coincidence (or tiny traces).
> > 
> > > But anyway explicit allocation is better here. Added.
> > > 

<snipped>

-- 
Best regards,
IM