From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 71EDE469719 for ; Thu, 8 Oct 2020 15:55:30 +0300 (MSK) Date: Thu, 8 Oct 2020 15:44:53 +0300 From: Igor Munkin Message-ID: <20201008124453.GT18920@tarantool.org> References: <2280bc3a2e32356455c3aebae711bafe2c4332f5.1601878708.git.skaplun@tarantool.org> <20201007141106.GP18920@tarantool.org> <20201007195558.GA20188@root> <20201007201601.GR18920@tarantool.org> <20201008101123.GB11972@root> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201008101123.GB11972@root> 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: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org 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