[Tarantool-patches] [PATCH v4 1/2] core: introduce various platform metrics
Sergey Ostanevich
sergos at tarantool.org
Fri Oct 9 17:39:48 MSK 2020
Hi!
Thanks for the patch. Although I was puzzled by your conversation over
MIPS registers use, stalled at the first reply 'added scratch register
allocation'. And I see the same first version in the branch.
The hand-scheduled MIPS code is cool also!
LGTM, I didn't manage to catch any inconsistence in inc/dec of stats.
Sergos.
On 08 окт 15:44, Igor Munkin wrote:
> 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
More information about the Tarantool-patches
mailing list