From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yerden Zhumabekov <e_zhumabekov-8EHiFRVJVgQ@public.gmane.org>
Subject: Re: [PATCH v4 3/5] hash: add fallback to software CRC32
	implementation
Date: Wed, 19 Nov 2014 17:35:51 +0600
Message-ID: <546C8097.6000509@sts.kz>
References: <1409724351-23786-1-git-send-email-e_zhumabekov@sts.kz>
 <cover.1416318389.git.e_zhumabekov@sts.kz>
 <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>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
To: Bruce Richardson <bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Neil Horman
 <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Return-path: <dev-bounces-VfR2kkLFssw@public.gmane.org>
In-Reply-To: <20141119101614.GA6532@bricha3-MOBL3>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev-VfR2kkLFssw@public.gmane.org>
List-Help: <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=subscribe>
Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org
Sender: "dev" <dev-bounces-VfR2kkLFssw@public.gmane.org>


19.11.2014 16:16, Bruce Richardson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> 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 wa=
y 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 mor=
e=20
> maintainable.
>

static inline uint32_t
crc32_sse42_u32(uint32_t data, uint32_t init_val)
{
/*=C2=B7=C2=B7__asm__ volatile(
=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7"=
crc32l %[data], %[init_val];"
=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7:=
 [init_val] "+r" (init_val)
=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7:=
 [data] "rm" (data));
=C2=B7=C2=B7=C2=B7=C2=B7return init_val;*/

But wait, will __builtin_ia32_crc32si and __builtin_ia32_crc32di
functions do the trick? ICC has them?
What about prototyping functions and extracting their bodies to separate
module? Does it break anything?

--=20
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ