RE: [xz-devel] patch for Intel compiler - use of Intel compiler intrinsics e.g. bit-scan-reverse

2018-01-10 Thread Blower, Melanie
 
> From: owner-xz-de...@tukaani.org [mailto:owner-xz-de...@tukaani.org] On
> Behalf Of Lasse Collin
> Sent: Wednesday, January 10, 2018 4:46 PM
> To: xz-devel@tukaani.org
> Subject: Re: [xz-devel] patch for Intel compiler - use of Intel compiler 
> intrinsics
> e.g. bit-scan-reverse
>  
> 
> Thanks! Committed.
[Blower, Melanie] Thanks a lot. 
> 
> > BTW I see there is something in "configure" to automatically include
> > immintrin.h and it's referred to in the file
> > ./src/liblzma/common/memcmplen.h; I'm not sure if that's working
> > correctly.
> 
> I'm quite sure it's working correctly. Check config.h after you have run
> configure. It should have
> 
> #define HAVE_IMMINTRIN_H 1
> 
> somewhere in it. If it doesn't, something needs to be fixed.
[Blower, Melanie] OK I'll check it.
> 
> It's not any kind of automatic include. configure only adds the above line to
> config.h, which the C code can use to test if the header is available for 
> use. So
> far it's used only in memcmplen.h because so far that was the only place where
> the intrinsics were needed.
> 
> memcmplen.h uses _BitScanForward64 on Windows. I believe I read some docs
> that it (among the preprocessor test "defined(_M_X64)") should work on Intel C
> compiler on Windows.
[Blower, Melanie] Yes that should work, I always need to test and verify to be 
absolutely certain
> 
> It would be useful if you could test memcmplen.h and verify that the Intel
> compiler specific #ifs and functions are correct even for the unreleased 
> version.
> There are five implementations of the same functionality in memcmplen.h. Four
> of these are compatible with 64-bit
> x86 (the big endian variant (fourth) isn't). The first two test for 
> preprocessor-
> specific macros and use compiler-specific code and thus are worth testing with
> Intel C compiler.
> 
> With Intel compiler, the first variant should get used on 64-bit x86 by 
> default. If
> you comment it out (or turn it to "#if 0"), the second version should get used
> instead. The second variant works on 32-bit x86 too, assuming that -march is 
> set
> so that SSE2 is available.
[Blower, Melanie] I'll see about this. It will take me some time
> 
> > I don't know how to configure the "git clone" from configure.ac--I
> > couldn't build.
> 
> If you have the required GNU tools installed, it's enough to run "autoreconf 
> -fi"
> to create "configure" and other build files.
> 
> > So I downloaded the tar.bz file for xz.5.2.3, configure and build on
> > Linux with CC=icc; in a separate build/ directory.
> 
> This is fine in this case. The files having compiler-specific code are 
> identical in
> the master branch.
> 
> > As well it is possible to get a free developer license for the Intel
> > c++ compiler for certain open source usages.
> 
> Thanks, but no thanks, at least for now. I know it could be useful for testing
> compiler-specific things, but since I already have trouble getting things 
> done, I
> probably am not going spend time on setting it up etc. in the foreseeable 
> future.
[Blower, Melanie] Understood!! 




Re: [xz-devel] patch for Intel compiler - use of Intel compiler intrinsics e.g. bit-scan-reverse

2018-01-10 Thread Lasse Collin
On 2018-01-08 Blower, Melanie wrote:
> I would like to submit this patch to xz to support the Intel compiler

Thanks! Committed.

> BTW I see there is something in "configure" to automatically include
> immintrin.h and it's referred to in the
> file ./src/liblzma/common/memcmplen.h; I'm not sure if that's working
> correctly.

I'm quite sure it's working correctly. Check config.h after you have
run configure. It should have

#define HAVE_IMMINTRIN_H 1

somewhere in it. If it doesn't, something needs to be fixed.

It's not any kind of automatic include. configure only adds the above
line to config.h, which the C code can use to test if the header is
available for use. So far it's used only in memcmplen.h because so far
that was the only place where the intrinsics were needed.

memcmplen.h uses _BitScanForward64 on Windows. I believe I read some
docs that it (among the preprocessor test "defined(_M_X64)") should
work on Intel C compiler on Windows.

It would be useful if you could test memcmplen.h and verify that the
Intel compiler specific #ifs and functions are correct even for the
unreleased version. There are five implementations of the same
functionality in memcmplen.h. Four of these are compatible with 64-bit
x86 (the big endian variant (fourth) isn't). The first two test for
preprocessor-specific macros and use compiler-specific code and thus
are worth testing with Intel C compiler.

With Intel compiler, the first variant should get used on 64-bit x86 by
default. If you comment it out (or turn it to "#if 0"), the second
version should get used instead. The second variant works on 32-bit x86
too, assuming that -march is set so that SSE2 is available.

> I don't know how to configure the "git clone" from
> configure.ac--I couldn't build.

If you have the required GNU tools installed, it's enough to run
"autoreconf -fi" to create "configure" and other build files.

> So I downloaded the tar.bz file for xz.5.2.3, configure and build on
> Linux with CC=icc; in a separate build/ directory.

This is fine in this case. The files having compiler-specific code are
identical in the master branch.

> As well it is possible to get a free developer
> license for the Intel c++ compiler for certain open source usages.

Thanks, but no thanks, at least for now. I know it could be useful for
testing compiler-specific things, but since I already have trouble
getting things done, I probably am not going spend time on setting
it up etc. in the foreseeable future.

> In any source file that refers to Intel intrinsics, there should be a
> #include of  to future-proof the usage.

I try to keep this in mind. Thanks!

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode