From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 7B88A469719 for ; Fri, 9 Oct 2020 17:39:49 +0300 (MSK) Date: Fri, 9 Oct 2020 17:39:48 +0300 From: Sergey Ostanevich Message-ID: <20201009143948.GB2885@tarantool.org> References: <2280bc3a2e32356455c3aebae711bafe2c4332f5.1601878708.git.skaplun@tarantool.org> <20201007141106.GP18920@tarantool.org> <20201007195558.GA20188@root> <20201007201601.GR18920@tarantool.org> <20201008101123.GB11972@root> <20201008124453.GT18920@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201008124453.GT18920@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v4 1/2] core: introduce various platform metrics List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org 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, > > > > > > > > > > > + 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. > > > > > > > > -- > Best regards, > IM