You are not logged in.
I built the intel compiler using the AUR PKGBUILD and have the following two components installed:
intel-compiler-base
intel-openmp
I'd like to compile the linux package with icc and I've read a few old threads and some closed bug reports. There seems to be some significant modification to the source tree to get it to work. Anyone done it successfully and care to share?
Edit: created a wiki page for Intel C++ - please contribute.
Last edited by graysky (2011-11-25 11:18:12)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I wasn't aware this was even possible until I saw this thread and did some googling. 40% potential performance increase eh?
I know that GCC does allow some non standard C and accepts some things other compilers don't.
Maybe the kernel source at: http://www.linuxdna.com/ is more compatible with icc.
Last edited by llawwehttam (2011-11-25 04:18:02)
Offline
linuxdna is dead unfortunately. out of curiosity graysky, did you ever try with clang ?
Offline
@bangkok - yes. I found that there are numerous edits to various files in the kernel source that need to take place for it to build correctly. Example on my system that uses a custom set of modules. This doesn't work on the ARCH set of modules.
--- a/Makefile 2011-11-24 16:50:26.277294221 -0500
+++ b/Makefile 2011-11-24 16:50:09.013725257 -0500
@@ -247,9 +247,9 @@
else if [ -x /bin/bash ]; then echo /bin/bash; \
else echo sh; fi ; fi)
-HOSTCC = gcc
+HOSTCC = icc
HOSTCXX = g++
-HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCFLAGS = -w -xHOST -O2 -fomit-frame-pointer
HOSTCXXFLAGS = -O2
# Decide whether to build built-in, modular, or both.
@@ -334,7 +334,7 @@
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
-CC = $(CROSS_COMPILE)gcc
+CC = $(CROSS_COMPILE)icc
CPP = $(CC) -E
AR = $(CROSS_COMPILE)ar
NM = $(CROSS_COMPILE)nm
@@ -565,7 +565,7 @@
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os
else
-KBUILD_CFLAGS += -O2
+KBUILD_CFLAGS += -O3
endif
include $(srctree)/arch/$(SRCARCH)/Makefile
--- a/arch/x86/Makefile 2011-10-24 03:10:05.000000000 -0400
+++ b/arch/x86/Makefile 2011-11-24 16:33:03.033261333 -0500
@@ -48,13 +48,14 @@
KBUILD_AFLAGS += -m64
KBUILD_CFLAGS += -m64
+ KBUILD_CFLAGS += -ffreestanding
# FIXME - should be integrated in Makefile.cpu (Makefile_32.cpu)
cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8)
cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona)
cflags-$(CONFIG_MCORE2) += \
- $(call cc-option,-march=core2,$(call cc-option,-mtune=generic))
+ $(call cc-option,-xHOST,$(call cc-option,-mtune=generic))
cflags-$(CONFIG_MATOM) += $(call cc-option,-march=atom) \
$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))
cflags-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=generic)
@@ -111,8 +112,6 @@
KBUILD_CFLAGS += -Wno-sign-compare
#
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-# prevent gcc from generating any FP code by mistake
-KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
KBUILD_CFLAGS += $(mflags-y)
KBUILD_AFLAGS += $(mflags-y)
--- a/arch/x86/include/asm/cpufeature.h 2011-10-24 03:10:05.000000000 -0400
+++ b/arch/x86/include/asm/cpufeature.h 2011-11-24 16:34:25.727686270 -0500
@@ -328,23 +328,7 @@
*/
static __always_inline __pure bool __static_cpu_has(u16 bit)
{
-#if __GNUC__ > 4 || __GNUC_MINOR__ >= 5
- asm goto("1: jmp %l[t_no]\n"
- "2:\n"
- ".section .altinstructions,\"a\"\n"
- " .long 1b - .\n"
- " .long 0\n" /* no replacement */
- " .word %P0\n" /* feature bit */
- " .byte 2b - 1b\n" /* source len */
- " .byte 0\n" /* replacement len */
- ".previous\n"
- /* skipping size check since replacement size = 0 */
- : : "i" (bit) : : t_no);
- return true;
- t_no:
- return false;
-#else
- u8 flag;
+ u8 flag;
/* Open-coded due to __stringify() in ALTERNATIVE() */
asm volatile("1: movb $0,%0\n"
"2:\n"
@@ -364,7 +348,6 @@
".previous\n"
: "=qm" (flag) : "i" (bit));
return flag;
-#endif
}
#define static_cpu_has(bit)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
thanks graysky but that obviously looks like a patch to build with icc, i was talking about clang, it should be able to build a linux kernel nowadays i guess. any experience with that?
Offline
Never did it before
Setting that variable doesn't change the errors when building with icc.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
graysky you are confusing me a lot
http://clang.llvm.org/
Offline
I've seen no mention of clang/llvm being able to build the linux kernel. There's quite alot of projects it fails to compile so that's not suprising. There's a new release coming soon though (actually it should be out but was postponed) which hopefully brings further fixes/compability resulting in more code being able to compile but I think if the linux kernel would be one of them then that would have been advertised. As for the results of compiling linux with clang/llvm it would likely just be slightly slower given that clang/llvm doesn't generate as fast code as gcc does (although it compiles faster and has better error reporting). I regularly compile my code with both compilers in order to better catch warnings as they sometimes find potential bugs which the other one ignores.
Offline
about a year ago, not sure about the situtation today:
http://lists.cs.uiuc.edu/pipermail/cfe- … 11711.html
Offline
about a year ago, not sure about the situtation today:
http://lists.cs.uiuc.edu/pipermail/cfe- … 11711.html
Yes, I remember reading this, IIRC it needed patching to compile and also parts of it still needed to be compiled with GCC and finally the resulting kernel was extremely broken.
Recently there was an announcement that Clang/LLVM built LibreOffice, however it again required source patching to build and the resulting binary didn't even run. So, no, there's still alot of work to be done on Clang before it becomes a mature frontend. And when it cleanly builds a working linux kernel, it WILL be announced.
As for ICC, while Clang/LLVM generates slower code than GCC, ICC generates slightly faster code than GCC on most things I've compiled. This is on a corei5/i7 though, if you have AMD hardware then that's likely not the case as it's heavily tuned to their own chipsets (even though they can no longer cripple the codepath for AMD cpu's which they did before in ICC).
Offline
I think it is indeed worth pointing out that using ICC for AMD CPUs is rather counterproductive.
Grinch, do you have a link about Intel not being allowed anymore to cripple the codepath for AMD CPUs? I have read about their doing it, but haven't heard anything yet about AMD getting them to 'fix' that.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
Well although there hasn't been any offical word AFAIK, AMD sued Intel over this and Intel settled after which a new flag was added to ICC (-xO) which enables sse3,sse2,sse optimizations for non-intel cpu's. Preciously any non-Intel cpu's would not use any sse optimization in ICC despite that cpuid (an instruction which Intel themselves added) clearly declared that the cpu supported those extensions. That said, even with SSE optimizations enabled ICC will certainly favour Intel cpu's given other differences between the cpu architectures (like caches, prefetching, branch prediction etc).
Offline
I don't want the thread to stray too far off topic. Please limit posts to enabling users to build the linux kernel with icc if anyone has the knowledge
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I think users are entitled to know the Intel compiler will not necessarily boost your system's performance, and it may be even detrimental for AMD users. I think we both agree that's important information that should not be left out of this thread, as it's pretty essential information for AMD users.
Besides that, sorry for going offtopic.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline