From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6968 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 1/2] x86_64/memset: simple optimizations Date: Tue, 10 Feb 2015 15:50:47 -0500 Message-ID: <20150210205047.GK23507@brightrain.aerifal.cx> References: <1423589457-8407-1-git-send-email-vda.linux@googlemail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423601463 19933 80.91.229.3 (10 Feb 2015 20:51:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2015 20:51:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6981-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 10 21:51:02 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YLHlt-00078T-Eb for gllmg-musl@m.gmane.org; Tue, 10 Feb 2015 21:51:01 +0100 Original-Received: (qmail 17484 invoked by uid 550); 10 Feb 2015 20:50:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17475 invoked from network); 10 Feb 2015 20:50:59 -0000 Content-Disposition: inline In-Reply-To: <1423589457-8407-1-git-send-email-vda.linux@googlemail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6968 Archived-At: On Tue, Feb 10, 2015 at 06:30:56PM +0100, Denys Vlasenko wrote: > "and $0xff,%esi" is a six-byte insn (81 e6 ff 00 00 00), can use > 4-byte "movzbl %sil,%esi" (40 0f b6 f6) instead. > [...] Do you want to go ahead with these patches as-is, or consider some of the other ideas we discussed off-list like avoiding the 64-bit imul entirely in the small-n case? If you think that's easy as another incremental change I'll go ahead with these, but if it's basically going to be backing out these first changes and replacing them with something different, I'm not sure if it makes sense to commit one then the other. Rich