From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id C17497FA4
 for <dev@dpdk.org>; Wed, 19 Nov 2014 15:57:16 +0100 (CET)
Received: from nat-pool-rdu-t.redhat.com ([66.187.233.202] helo=localhost)
 by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
 (envelope-from <nhorman@tuxdriver.com>)
 id 1Xr6qw-0001eM-SK; Wed, 19 Nov 2014 10:07:36 -0500
Date: Wed, 19 Nov 2014 10:07:25 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Yerden Zhumabekov <e_zhumabekov@sts.kz>
Message-ID: <20141119150725.GB28013@localhost.localdomain>
References: <a875a94021448514bfbcf1409e4303cde50882f3.1416318389.git.e_zhumabekov@sts.kz>
 <20141118144138.GB32375@hmsreliant.think-freely.org>
 <546B607B.9030808@sts.kz>
 <20141118160005.GC32375@hmsreliant.think-freely.org>
 <546B7E2D.7050705@sts.kz>
 <20141118174619.GE32375@hmsreliant.think-freely.org>
 <20141118175226.GC5840@bricha3-MOBL3>
 <20141118213624.GF32375@hmsreliant.think-freely.org>
 <20141119101614.GA6532@bricha3-MOBL3> <546C8097.6000509@sts.kz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <546C8097.6000509@sts.kz>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: -2.9 (--)
X-Spam-Status: No
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32
 implementation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 14:57:17 -0000

On Wed, Nov 19, 2014 at 05:35:51PM +0600, Yerden Zhumabekov wrote:
> 
> 19.11.2014 16:16, Bruce Richardson пишет:
> > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> >> an alternate option would be to not use the intrinsic, and craft some explicit
> >> __asm__ statement that executes the right sse42 instructions.  That way the asm
> >> is directly emitted, without requiring the -msse42 flag at all, and it will just
> >> work in all the files that call it.
> >>
> > I really don't like that approach. I think using intrinsics is much more 
> > maintainable.
> >
> 
> static inline uint32_t
> crc32_sse42_u32(uint32_t data, uint32_t init_val)
> {
> /*··__asm__ volatile(
> ············"crc32l %[data], %[init_val];"
> ············: [init_val] "+r" (init_val)
> ············: [data] "rm" (data));
> ····return init_val;*/
> 
> But wait, will __builtin_ia32_crc32si and __builtin_ia32_crc32di
> functions do the trick? ICC has them?
If builtins work on both icc and gcc, yes, that would be a solution as it
creates non sse instructions when the target cpu doesn't support it.

> What about prototyping functions and extracting their bodies to separate
> module? Does it break anything?
> 
That would be a variant on the asm inline idea, but yes, I think that would work
too
Neil


> -- 
> Sincerely,
> 
> Yerden Zhumabekov
> State Technical Service
> Astana, KZ
> 
>