From: Jeffrey Walton Subject: Re: [PATCH] crypto: gf128mul - define gf128mul_x_ble in gf128mul.h Date: Fri, 31 Mar 2017 02:05:02 -0400 Message-ID: References: <20170330192535.23123-1-omosnacek@gmail.com> <20170330195546.GA60896@gmail.com> Reply-To: noloader@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: linux-crypto@vger.kernel.org To: =?UTF-8?B?T25kcmVqIE1vc27DocSNZWs=?= Return-path: Received: from mail-oi0-f53.google.com ([209.85.218.53]:35365 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750723AbdCaGFE (ORCPT ); Fri, 31 Mar 2017 02:05:04 -0400 Received: by mail-oi0-f53.google.com with SMTP id f193so51429778oib.2 for ; Thu, 30 Mar 2017 23:05:03 -0700 (PDT) In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: >> Also note that '(b & ((u64)1 << 63)) ? 0x87 : 0x00;' is actually getting >> compiled as '((s64)b >> 63) & 0x87', which is branchless and therefore makes the >> new version more efficient than one might expect: >> >> sar $0x3f,%rax >> and $0x87,%eax >> >> It could even be written the branchless way explicitly, but it shouldn't matter. > > I think the definition using unsigned operations is more intuitive... > Let's just leave the clever tricks up to the compiler :) It may be a good idea to use the one that provides constant time-ness to help avoid leaking information. Jeff