From owner-cvs-src@FreeBSD.ORG Sat Jun 28 11:44:22 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 31F98106566C; Sat, 28 Jun 2008 11:44:22 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 97D628FC30; Sat, 28 Jun 2008 11:44:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id m5SBiHeG034743; Sat, 28 Jun 2008 13:44:17 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id m5SBiHMC034742; Sat, 28 Jun 2008 13:44:17 +0200 (CEST) (envelope-from marius) Date: Sat, 28 Jun 2008 13:44:17 +0200 From: Marius Strobl To: Christoph Mallon Message-ID: <20080628114417.GL1215@alchemy.franken.de> References: <200806252105.m5PL5AUp064418@repoman.freebsd.org> <48654667.1040401@gmx.de> <20080627222404.GJ1215@alchemy.franken.de> <48657058.6020102@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48657058.6020102@gmx.de> User-Agent: Mutt/1.4.2.3i 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: Sat, 28 Jun 2008 11:44:22 -0000 On Sat, Jun 28, 2008 at 12:57:28AM +0200, Christoph Mallon wrote: > 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. With GCC 4.2.1 at -O2 the code generated for the above C version takes on more instruction than the inline assembler so if one wants to go for micro-optimizing one should certainly prefer the inline assembler version. > > 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. > The "&"-modifiers are necessary as the inline assembler in question consumes output operands before all input operands are consumed. Omitting them caused GCC to generate broken code in the past. Marius