build: remove support for icc compiler
Checks
Commit Message
The Intel-produced compiler "icc" has been replaced by the newer
clang-based "icx" compiler. DPDK compilation has also not been tested
recently with the icc compiler, so let's remove doc and code references
to icc, and any special macros or build support that was added for it.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test_pie.c | 5 -----
app/test/test_red.c | 5 -----
.../contributing/img/patch_cheatsheet.svg | 2 +-
doc/guides/linux_gsg/sys_reqs.rst | 3 ---
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/hinic.rst | 1 -
doc/guides/nics/hns3.rst | 1 -
doc/guides/nics/ngbe.rst | 1 -
doc/guides/nics/txgbe.rst | 1 -
doc/guides/prog_guide/lto.rst | 2 +-
.../prog_guide/writing_efficient_code.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 19 -------------------
drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 2 +-
drivers/net/virtio/meson.build | 2 --
drivers/net/virtio/virtio_rxtx_packed.h | 5 -----
dts/framework/config/__init__.py | 2 --
dts/framework/testbed_model/posix_session.py | 2 --
lib/eal/include/rte_common.h | 6 ++----
lib/eal/x86/include/rte_rtm.h | 2 +-
lib/eal/x86/include/rte_vect.h | 13 -------------
lib/sched/rte_pie.c | 4 ----
lib/sched/rte_red.c | 4 ----
lib/sched/rte_sched.c | 5 -----
lib/vhost/meson.build | 2 --
lib/vhost/vhost.h | 5 -----
25 files changed, 8 insertions(+), 90 deletions(-)
Comments
On Wed, 5 Feb 2025 16:18:19 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:
> The Intel-produced compiler "icc" has been replaced by the newer
> clang-based "icx" compiler. DPDK compilation has also not been tested
> recently with the icc compiler, so let's remove doc and code references
> to icc, and any special macros or build support that was added for it.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Probably should add a release note for this. But overall looks like a great idea.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
On Wed, Feb 5, 2025 at 5:19 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> The Intel-produced compiler "icc" has been replaced by the newer
> clang-based "icx" compiler. DPDK compilation has also not been tested
> recently with the icc compiler, so let's remove doc and code references
> to icc, and any special macros or build support that was added for it.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
I noticed remaining references, from which some can be cleaned up too:
app/test-pmd/testpmd.h: * Work-around of a compilation error with ICC
on invocations of the
lib/eal/common/eal_common_dynmem.c: /* to prevent
icc errors */
lib/eal/x86/include/rte_vect.h:#if defined(__ICC) || defined(_WIN64)
buildtools/check-symbols.sh:# Filter out symbols suffixed with a . for icc
buildtools/check-symbols.sh:# Filter out symbols suffixed with a . for icc
And please add a release note update.
Thanks.
On Wed, Feb 05, 2025 at 06:03:16PM +0100, David Marchand wrote:
> On Wed, Feb 5, 2025 at 5:19 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > The Intel-produced compiler "icc" has been replaced by the newer
> > clang-based "icx" compiler. DPDK compilation has also not been tested
> > recently with the icc compiler, so let's remove doc and code references
> > to icc, and any special macros or build support that was added for it.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> I noticed remaining references, from which some can be cleaned up too:
>
> app/test-pmd/testpmd.h: * Work-around of a compilation error with ICC
> on invocations of the
>
Yes, I spotted this and a few of the others too - but forgot to reference
them in the commit log ntoes.
The trouble is that for a number of these cases I've no idea what specific
part of the code the workaround is, or what it should look like without the
workaround.
For this specific instance, the ifdefs in the testpmd.h file just refer to
GCC and non-GCC (presumably including clang), so it doesn't seem that there
is code that is ICC specific. Shall I just remove the comment?
> lib/eal/common/eal_common_dynmem.c: /* to prevent
> icc errors */
Same here. It's not clear to me what way the code should be reworked if not
supporting ICC. Again, I can just remove the comment and be done with it.
> lib/eal/x86/include/rte_vect.h:#if defined(__ICC) || defined(_WIN64)
>
This seems as miss on my part. Will fix in a v2.
> buildtools/check-symbols.sh:# Filter out symbols suffixed with a . for icc
> buildtools/check-symbols.sh:# Filter out symbols suffixed with a . for icc
>
This you may be able to advise me on. I assume that the icc-specific bit is
just he "&& !($NF ~ /\.$/)" bit, and not the whole block the comment is put
on?
> And please add a release note update.
>
Yes.
I've also been testing with the newer "icx" and will probably add something
in the docs about it working ok as a replacement.
/Bruce
On Wed, Feb 05, 2025 at 05:32:11PM +0000, Bruce Richardson wrote:
> On Wed, Feb 05, 2025 at 06:03:16PM +0100, David Marchand wrote:
> > On Wed, Feb 5, 2025 at 5:19 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > The Intel-produced compiler "icc" has been replaced by the newer
> > > clang-based "icx" compiler. DPDK compilation has also not been tested
> > > recently with the icc compiler, so let's remove doc and code references
> > > to icc, and any special macros or build support that was added for it.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >
> > I noticed remaining references, from which some can be cleaned up too:
> >
> > app/test-pmd/testpmd.h: * Work-around of a compilation error with ICC
> > on invocations of the
> >
>
> Yes, I spotted this and a few of the others too - but forgot to reference
> them in the commit log ntoes.
>
> The trouble is that for a number of these cases I've no idea what specific
> part of the code the workaround is, or what it should look like without the
> workaround.
>
> For this specific instance, the ifdefs in the testpmd.h file just refer to
> GCC and non-GCC (presumably including clang), so it doesn't seem that there
> is code that is ICC specific. Shall I just remove the comment?
>
> > lib/eal/common/eal_common_dynmem.c: /* to prevent
> > icc errors */
>
> Same here. It's not clear to me what way the code should be reworked if not
> supporting ICC. Again, I can just remove the comment and be done with it.
>
> > lib/eal/x86/include/rte_vect.h:#if defined(__ICC) || defined(_WIN64)
> >
>
> This seems as miss on my part. Will fix in a v2.
>
> > buildtools/check-symbols.sh:# Filter out symbols suffixed with a . for icc
> > buildtools/check-symbols.sh:# Filter out symbols suffixed with a . for icc
> >
>
> This you may be able to advise me on. I assume that the icc-specific bit is
> just he "&& !($NF ~ /\.$/)" bit, and not the whole block the comment is put
> on?
>
There is also a reference in ena driver, again, not sure what the correct
code replacement is - setting the struct initializer to {0} perhaps? Adding
some ena maintainers on CC so they can comment on this.
struct ena_com_create_io_ctx ctx =
/* policy set to _HOST just to satisfy icc compiler */
{ ENA_ADMIN_PLACEMENT_POLICY_HOST,
0, 0, 0, 0, 0 };
Ena maintainers - any suggestions on what the code should look like if we
no longer have to support the icc compiler?
/Bruce
@@ -41,11 +41,6 @@ test_pie_all(void)
#include <rte_pie.h>
-#ifdef __INTEL_COMPILER
-#pragma warning(disable:2259) /* conversion may lose significant bits */
-#pragma warning(disable:181) /* Arg incompatible with format string */
-#endif
-
/**< structures for testing rte_pie performance and function */
struct test_rte_pie_config { /**< Test structure for RTE_PIE config */
struct rte_pie_config *pconfig; /**< RTE_PIE configuration parameters */
@@ -40,11 +40,6 @@ test_red_all(void)
#include <rte_red.h>
-#ifdef __INTEL_COMPILER
-#pragma warning(disable:2259) /* conversion may lose significant bits */
-#pragma warning(disable:181) /* Arg incompatible with format string */
-#endif
-
#define TEST_HZ_PER_KHZ 1000
#define TEST_NSEC_MARGIN 500 /**< nanosecond margin when calculating clk freq */
@@ -718,7 +718,7 @@
style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7"
y="454.36987"
- x="49.093246">+ build gcc icc clang </tspan></text>
+ x="49.093246">+ build gcc clang </tspan></text>
<text
style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
@@ -71,9 +71,6 @@ Compilation of the DPDK
**Optional Tools:**
-* Intel\ |reg| C++ Compiler (icc). For installation, additional libraries may be required.
- See the icc Installation Guide found in the Documentation directory under the compiler installation.
-
* IBM\ |reg| Advance ToolChain for Powerlinux. This is a set of open source development tools and runtime libraries
which allows users to take leading edge advantage of IBM's latest POWER hardware features on Linux. To install
it, see the IBM official installation document.
@@ -378,7 +378,7 @@ AVX2 SIMD instructions. It is meant for bulk, throughput oriented workloads
where reducing cycles/packet in PMD is a priority. In order to use the
vectorized handler, take the following steps.
-- Use a recent version of gcc, icc, or clang and build 64-bit DPDK. If
+- Use a recent version of gcc or clang and build 64-bit DPDK. If
the compiler is known to support AVX2, DPDK build system
automatically compiles the vectorized handler. Otherwise, the
handler is not available.
@@ -55,5 +55,4 @@ for details.
Limitations or Known issues
---------------------------
-Build with ICC is not supported yet.
X86-32, Power8, ARMv7 and BSD are not supported yet.
@@ -451,5 +451,4 @@ sve burst function. When enabling IEEE 1588, Rx/Tx burst mode should be
simple or common. It is recommended that enable IEEE 1588 before ethdev
start. In this way, the correct Rx/Tx burst function can be selected.
-Build with ICC is not supported yet.
X86-32, Power8, ARMv7 and BSD are not supported yet.
@@ -81,5 +81,4 @@ for details.
Limitations or Known issues
---------------------------
-Build with ICC is not supported yet.
Power8, ARMv7 and BSD are not supported yet.
@@ -186,5 +186,4 @@ For a detailed usage description please refer to "Traffic Management" section in
Limitations or Known issues
---------------------------
-Build with ICC is not supported yet.
Power8, ARMv7 and BSD are not supported yet.
@@ -10,7 +10,7 @@ program" optimization at link time and is available only for compilers
that support that feature.
To be more specific, compiler (in addition to performing LTO) have to
support creation of ELF objects containing both normal code and internal
-representation (called fat-lto-objects in gcc and icc).
+representation (called fat-lto-objects in gcc).
This is required since during build some code is generated by parsing
produced ELF objects (pmdinfogen).
@@ -247,7 +247,7 @@ However, this technique is not always efficient; it depends on many factors incl
Branch Prediction
~~~~~~~~~~~~~~~~~
-The Intel® C/C++ Compiler (icc)/gcc built-in helper functions likely() and unlikely()
+The gcc built-in helper functions likely() and unlikely()
allow the developer to indicate if a code branch is likely to be taken or not.
For instance:
@@ -422,25 +422,6 @@ Differences in how different Intel NICs handle maximum packet length for jumbo f
Poll Mode Driver (PMD).
-GCC might generate Intel® AVX instructions for processors without Intel® AVX support
-------------------------------------------------------------------------------------
-
-**Description**:
- When compiling DPDK (and any DPDK app), gcc may generate Intel® AVX instructions, even when the
- processor does not support Intel® AVX.
-
-**Implication**:
- Any DPDK app might crash while starting up.
-
-**Resolution/Workaround**:
- Either compile using icc or set ``EXTRA_CFLAGS='-O3'`` prior to compilation.
-
-**Affected Environment/Platform**:
- Platforms which processor does not support Intel® AVX.
-
-**Driver/Module**:
- Environment Abstraction Layer (EAL).
-
Ethertype filter could receive other packets (non-assigned) in Niantic
----------------------------------------------------------------------
@@ -25,7 +25,7 @@
#include "mlx5_rxtx_vec.h"
#include "mlx5_autoconf.h"
-#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
+#if !defined(RTE_TOOLCHAIN_MSVC)
#pragma GCC diagnostic ignored "-Wstrict-aliasing"
#endif
@@ -37,8 +37,6 @@ if arch_subdir == 'x86'
cflags += '-DVIRTIO_GCC_UNROLL_PRAGMA'
elif (toolchain == 'clang' and cc.version().version_compare('>=3.7.0'))
cflags += '-DVIRTIO_CLANG_UNROLL_PRAGMA'
- elif (toolchain == 'icc' and cc.version().version_compare('>=16.0.0'))
- cflags += '-DVIRTIO_ICC_UNROLL_PRAGMA'
endif
endif
sources += files('virtio_rxtx_simple_sse.c')
@@ -77,11 +77,6 @@
for (iter = val; iter < size; iter++)
#endif
-#ifdef VIRTIO_ICC_UNROLL_PRAGMA
-#define virtio_for_each_try_unroll(iter, val, size) _Pragma("unroll 4") \
- for (iter = val; iter < size; iter++)
-#endif
-
#ifndef virtio_for_each_try_unroll
#define virtio_for_each_try_unroll(iter, val, size) \
for (iter = val; iter < size; iter++)
@@ -116,8 +116,6 @@ class Compiler(StrEnum):
#:
clang = auto()
#:
- icc = auto()
- #:
msvc = auto()
@@ -381,8 +381,6 @@ def get_compiler_version(self, compiler_name: str) -> str:
).stdout.split("\n")[0]
case "msvc":
return self.send_command("cl", SETTINGS.timeout).stdout
- case "icc":
- return self.send_command(f"{compiler_name} -V", SETTINGS.timeout).stdout
case _:
raise ValueError(f"Unknown compiler {compiler_name}")
@@ -59,8 +59,6 @@ extern "C" {
#define RTE_CC_IS_GNU 0
#if defined __clang__
#define RTE_CC_CLANG
-#elif defined __INTEL_COMPILER
-#define RTE_CC_ICC
#elif defined __GNUC__
#define RTE_CC_GCC
#undef RTE_CC_IS_GNU
@@ -160,7 +158,7 @@ typedef uint16_t unaligned_uint16_t;
* Macros to cause the compiler to remember the state of the diagnostics as of
* each push, and restore to that point at each pop.
*/
-#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
+#if !defined(RTE_TOOLCHAIN_MSVC)
#define __rte_diagnostic_push _Pragma("GCC diagnostic push")
#define __rte_diagnostic_pop _Pragma("GCC diagnostic pop")
#else
@@ -172,7 +170,7 @@ typedef uint16_t unaligned_uint16_t;
* Macro to disable compiler warnings about removing a type
* qualifier from the target type.
*/
-#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
+#if !defined(RTE_TOOLCHAIN_MSVC)
#define __rte_diagnostic_ignored_wcast_qual _Pragma("GCC diagnostic ignored \"-Wcast-qual\"")
#else
#define __rte_diagnostic_ignored_wcast_qual
@@ -7,7 +7,7 @@
#include <immintrin.h>
-/* Official RTM intrinsics interface matching gcc/icc, but works
+/* Official RTM intrinsics interface matching gcc, but works
on older gcc compatible compilers and binutils. */
#include <rte_common.h>
@@ -74,19 +74,6 @@ __extension__ ({ \
})
#endif
-/*
- * Prior to version 12.1 icc doesn't support _mm_set_epi64x.
- */
-#if (defined(__ICC) && __ICC < 1210)
-#define _mm_set_epi64x(a, b) \
-__extension__ ({ \
- rte_xmm_t m; \
- m.u64[0] = b; \
- m.u64[1] = a; \
- (m.x); \
-})
-#endif /* (defined(__ICC) && __ICC < 1210) */
-
#ifdef __AVX512F__
#define RTE_X86_ZMM_SIZE (sizeof(__m512i))
@@ -9,10 +9,6 @@
#include "rte_sched_log.h"
#include "rte_pie.h"
-#ifdef __INTEL_COMPILER
-#pragma warning(disable:2259) /* conversion may lose significant bits */
-#endif
-
int
rte_pie_rt_data_init(struct rte_pie *pie)
{
@@ -7,10 +7,6 @@
#include <rte_random.h>
#include <rte_common.h>
-#ifdef __INTEL_COMPILER
-#pragma warning(disable:2259) /* conversion may lose significant bits */
-#endif
-
static int rte_red_init_done = 0; /**< Flag to indicate that global initialisation is done */
uint32_t rte_red_rand_val = 0; /**< Random value cache */
uint32_t rte_red_rand_seed = 0; /**< Seed for random number generation */
@@ -22,11 +22,6 @@
#include "rte_approx.h"
-
-#ifdef __INTEL_COMPILER
-#pragma warning(disable:2259) /* conversion may lose significant bits */
-#endif
-
#ifndef RTE_SCHED_PORT_N_GRINDERS
#define RTE_SCHED_PORT_N_GRINDERS 8
#endif
@@ -12,8 +12,6 @@ if (toolchain == 'gcc' and cc.version().version_compare('>=8.3.0'))
cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
elif (toolchain == 'clang' and cc.version().version_compare('>=3.7.0'))
cflags += '-DVHOST_CLANG_UNROLL_PRAGMA'
-elif (toolchain == 'icc' and cc.version().version_compare('>=16.0.0'))
- cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
endif
dpdk_conf.set('RTE_LIBRTE_VHOST_POSTCOPY', cc.has_header('linux/userfaultfd.h'))
cflags += [
@@ -79,11 +79,6 @@
for (iter = val; iter < size; iter++)
#endif
-#ifdef VHOST_ICC_UNROLL_PRAGMA
-#define vhost_for_each_try_unroll(iter, val, size) _Pragma("unroll (4)") \
- for (iter = val; iter < size; iter++)
-#endif
-
#ifndef vhost_for_each_try_unroll
#define vhost_for_each_try_unroll(iter, val, num) \
for (iter = val; iter < num; iter++)