From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7042
Path: news.gmane.org!not-for-mail
From: Denys Vlasenko <vda.linux@googlemail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: [PATCH] x86_64/memset: use "small block" code for blocks
 up to 30 bytes long
Date: Sun, 15 Feb 2015 15:07:06 +0100
Message-ID: <CAK1hOcPQ=mADeAUP3i-Xt3rvHmgUrVVoz2yUEOkUEYQ2xRVN2g@mail.gmail.com>
References: <1423845589-5920-1-git-send-email-vda.linux@googlemail.com>
 <20150214193533.GK23507@brightrain.aerifal.cx> <20150215040655.GM23507@brightrain.aerifal.cx>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Trace: ger.gmane.org 1424009301 17697 80.91.229.3 (15 Feb 2015 14:08:21 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 15 Feb 2015 14:08:21 +0000 (UTC)
To: musl <musl@lists.openwall.com>
Original-X-From: musl-return-7055-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 15 15:08:21 2015
Return-path: <musl-return-7055-gllmg-musl=m.gmane.org@lists.openwall.com>
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 <musl-return-7055-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1YMzru-0004vX-Ue
	for gllmg-musl@m.gmane.org; Sun, 15 Feb 2015 15:08:19 +0100
Original-Received: (qmail 20221 invoked by uid 550); 15 Feb 2015 14:08:17 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 20035 invoked from network); 15 Feb 2015 14:07:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        bh=+PzoMunlDIMCCy8KimApHqvs5YmntOlECJBb8SKvKSQ=;
        b=Vf5ut1fpIqcovAkXDc8wIFVIW2Doz6erTkShnzzs7CLloqMINiNJR7U2VmkauRgRdH
         l8NvxKkeezhLYTi6/htn6mApKzTPh1hLg5h0jBuMvtdjOloTdl4K/QOXqRNRDophyQ4S
         8tZgl/vDULOP/ejfiXVk8Cd6kxPquMJs+SP8ZrroGKC4JbTAzRBxL0S98CRAMO59DCf6
         LHvtBT0MxBhP1g7HAMm/8h92XrZiMmykBHbrCmmxIF7CoS4bq01pWf+d8ED7soPo0vtm
         7nqYc3suiFhBabuUDWGL+I7X89y7d3hAPuwEdJW3ZzzQKycEkiJ3Lgg0INAu4zGWQsp5
         VNZw==
X-Received: by 10.140.38.197 with SMTP id t63mr37302250qgt.61.1424009246721;
 Sun, 15 Feb 2015 06:07:26 -0800 (PST)
In-Reply-To: <20150215040655.GM23507@brightrain.aerifal.cx>
Xref: news.gmane.org gmane.linux.lib.musl.general:7042
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/7042>

On Sun, Feb 15, 2015 at 5:06 AM, Rich Felker <dalias@libc.org> wrote:
>> The main change whose value I really question is the conditional
>> widen_rax. If the value isn't used until a few cycles after the imul
>> instruction, doing it unconditionally is probably cheaper than testing
>> and branching even when the branch is predictable.
>
> To elaborate, simply replacing the unconditional imul with an
> unconditional xor %eax,%eax in my best variant so far, I was only able
> to save one cycle. So I don't see any way a test, branch, and
> conditional imul could be less expensive than the unconditional imul.

So imul elimination is a (tiny) win even on our CPUs, which happen
to be the _fastest_ CPUs in regards to 64x64 imul (3 cycles).

Just because we don't personally see a hit from 6-cycle imul of AMD CPUs,
it does not mean people who do use those CPUs don't exist. Have heart...