From mboxrd@z Thu Jan  1 00:00:00 1970
From: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Subject: Re: [PATCH v4 3/5] hash: add fallback to software CRC32
 implementation
Date: Wed, 19 Nov 2014 10:07:25 -0500
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-Transfer-Encoding: quoted-printable
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
To: Yerden Zhumabekov <e_zhumabekov-8EHiFRVJVgQ@public.gmane.org>
Return-path: <dev-bounces-VfR2kkLFssw@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <546C8097.6000509-8EHiFRVJVgQ@public.gmane.org>
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>

On Wed, Nov 19, 2014 at 05:35:51PM +0600, Yerden Zhumabekov wrote:
>=20
> 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 som=
e 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 m=
ore=20
> > maintainable.
> >
>=20
> 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;*/
>=20
> 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 separat=
e
> module? Does it break anything?
>=20
That would be a variant on the asm inline idea, but yes, I think that wou=
ld work
too
Neil


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