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 <immintrin.h> to future-proof the usage.
I try to keep this in mind. Thanks!
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
