From owner-cvs-src@FreeBSD.ORG Fri Jun 27 22:57:30 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD191065682 for ; Fri, 27 Jun 2008 22:57:30 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 553B78FC1C for ; Fri, 27 Jun 2008 22:57:30 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 27 Jun 2008 22:57:28 -0000 Received: from p54A3C7AC.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.199.172] by mail.gmx.net (mp023) with SMTP; 28 Jun 2008 00:57:28 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1818Lp3FzY1MGSG1Xm1DkXqPy3AgPSyMEwBtoJDGD hXdCcp4EAhd3Me Message-ID: <48657058.6020102@gmx.de> Date: Sat, 28 Jun 2008 00:57:28 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.9 (X11/20071230) MIME-Version: 1.0 To: Marius Strobl References: <200806252105.m5PL5AUp064418@repoman.freebsd.org> <48654667.1040401@gmx.de> <20080627222404.GJ1215@alchemy.franken.de> In-Reply-To: <20080627222404.GJ1215@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sparc64/include in_cksum.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2008 22:57:31 -0000 Marius Strobl wrote: > I wasn't aware that the clobber list allows to explicitly specify > the condition codes, thanks for the hint. Though it unfortunately > took me longer than two days to verify it's effect on the generated > code; sparc64 could still have been one of the archs where "cc" has > no effect. Besides I don't think using "__volatile" for this is > that wrong, given that the sparc64 code generated by using "cc" > and "__volatile" is nearly identical and given that at least i386 > relies on "__volatile" telling GCC that the inline assembler uses > the condition codes since quite some time. So the condition codes > are probably part of what GCC treats as "important side-effects". If this is true and GCC only handles the eflags on x86 correctly, when __volatile is used, but not if "cc" is marked as clobbered, then this is clearly a bug. > Regarding the MFC, they don't happen automatically and the change > was not wrong in general so there was no need to hurry :) I still think, using __volatile only works by accident. volatile for an assembler block mostly means "this asm statement has an effect, even though the register specification looks otherwise, so do not optimise this away (i.e. no CSE, do not remove if result is unused etc.). On a related note: Is inline assembler really necessary here? For example couldn't in_addword() be written as static __inline u_short in_addword(u_short const sum, u_short const b) { u_int const t = sum + b; return t + (t >> 16); } ? This should at least produce equally good code and because the compiler has more knowledge about it than an assembler block, it potentially leads to better code. I have no SPARC compiler at hand, though. In fact the in/out specification for this asm block looks rather bad: "=&r" (__ret), "=&r" (__tmp) : "r" (sum), "r" (b) : "cc"); The "&"-modifiers (do not use the same registers as for any input operand value) force the compiler to use 4 (!) register in total for this asm block. It could be done with 2 registers if a proper in/out specification was used. At the very least the in/out specification can be improved, but I suspect using plain C is the better choice. Regards Christoph