From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T91DE-0005o1-UP for qemu-devel@nongnu.org; Tue, 04 Sep 2012 18:03:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T91DD-0008TB-Qu for qemu-devel@nongnu.org; Tue, 04 Sep 2012 18:03:12 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:43013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T91DD-0008T7-I5 for qemu-devel@nongnu.org; Tue, 04 Sep 2012 18:03:11 -0400 Received: by dadn15 with SMTP id n15so4516580dad.4 for ; Tue, 04 Sep 2012 15:03:10 -0700 (PDT) Sender: Richard Henderson Message-ID: <50467A9C.9040104@twiddle.net> Date: Tue, 04 Sep 2012 15:03:08 -0700 From: Richard Henderson MIME-Version: 1.0 References: <5955be78eb92f05b5fafa58477c543f89afaf39c.1346606812.git.blauwirbel@gmail.com> <50464BA2.5070209@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/21] target-s390x: split FPU ops List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org, Alexander Graf On 09/04/2012 12:40 PM, Blue Swirl wrote: > On Tue, Sep 4, 2012 at 6:42 PM, Richard Henderson wrote: >> On 09/02/2012 10:33 AM, Blue Swirl wrote: >>> +/* fpu_helper.c */ >>> +uint32_t set_cc_f32(float32 v1, float32 v2); >>> +uint32_t set_cc_f64(float64 v1, float64 v2); >>> +uint32_t set_cc_nz_f32(float32 v); >>> +uint32_t set_cc_nz_f64(float64 v); >>> + >> >> I think that the CC handling should stay together, regardless of FPU-ness. >> These functions are quite small and can be usefully inlined by the compiler. >> >> OTOH, this is much easier to do with my translate.c rewrite, so maybe I'll >> just take responsibility for moving them back... > > The problem is that these are used by some FPU ops as well as > condition code ops. Maybe it's better to move them to cpu.h as inline > functions? Maybe... > It could be also possible to upgrade condition code functions to full > helpers, that could help implementing lazy condition code evaluation. Done and ... > I noticed that the helpers don't use TCGv registers for register > access but instead the helpers access env->regs[] and env->fregs[] > directly, this probably would need to be changed too. done, in my rewrite. Except for float128, where we can't return such by value inside TCG. And, annoyingly, s390 float128 values are held in %fN/%fN+2, so the values are not contiguous in memory. I momentarily considered passing a pointer to %fN, letting the helper access f[0]/f[2], but in the end I didn't consider that any better than just passing the integer N. So after the rewrite, set_cc_nz_f32/64 are not referenced from the fp helpers directly. We still reference set_cc_nz_f128 from ADXBR and SDXBR. r~