From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 04AD343927; Mon, 22 Jan 2024 11:55:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 85E4B40291; Mon, 22 Jan 2024 11:55:21 +0100 (CET) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by mails.dpdk.org (Postfix) with ESMTP id 07CD54028B for ; Mon, 22 Jan 2024 11:55:19 +0100 (CET) Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a308e6824ccso15745966b.0 for ; Mon, 22 Jan 2024 02:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1705920919; x=1706525719; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aij5Q91qCSufuU4v+9a24P2w9A7Rt+Bcpl1GBPdr9ys=; b=cxJiqpUSL/Z6fbDvFVTPF9DJ4S7sOypdDtBmDb8eaB2rqIbKzontU7usiFXlEnGbOO J+0PH+T68mhXvhYXph3h4ip/Uz51Zqjy7kf2+EwCB4gSNh8P5/qqW1XX5tnlk8pveXw6 jhVlE0b/HgcrX4jXSc4YuPDDXzFLL05wex1Gfvnr1XV8oz/ubsZ1s8N5Wni6jvYSDJl6 6QUZsnFyTEV+Udu7RXTfYWBVkRx8M/OIR9+r1Ww8E1/m6K6E9g+YIP/hBAjNKOdThPxw fnE1q8+Yzwe7NBnuLAjvNAy7Z7dtkke2ZWagCelxaFix4zMb1zzx5SAWHQm5/0cJqBpU WPrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705920919; x=1706525719; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aij5Q91qCSufuU4v+9a24P2w9A7Rt+Bcpl1GBPdr9ys=; b=B3uzESQRgM/pJ3eKZW/4pUERNU5tpFbnNzuj2utKh8zW7GJAjdk6C7BKVZiqbYnrIy 7F4KTeqLfun6f4kIBjoNXPE4q3GDwTMLOYYESe6ZMwdWYK7udLhTy8HA3gBmyT7gx3ya y0iwddMrYzlaIG0Xj+xhdrVUsHyIWejf6gn4XEd1bK09iceVHi2IAOmMobEzjQGvx2Te XxhFhEQBk9he8zRq7jeg9ZEdwNvbeGInTff2OTAgjPLW51dyZFMOBxcO4v8kyqmHbBiH QffbEiJmj6CXeBjUQp/wDELPPJpWETJHVOvPUpv6hy+WnApooaaGS56ZvikSyGywf8Wu tdvg== X-Gm-Message-State: AOJu0YxgP6eiQJBfFKnSfx9uVcOhdTuwUo3vngq0m+WelSRqc+p8x/oo cTRZBKOuJxDVxvsOSQoOUDoy8o5ImklkYwj953Pvo6eDtiYVtZhvWzCcpnP6soXT4PUOoaShGJx BTdAVpnxXK0fDr2WmPxhvj4eo8F9nDa8jsNndAQ== X-Google-Smtp-Source: AGHT+IHVdY01MocEUda1TIJBp1d6ZGgPdIG0trA6a7wvEJ8jySes2aOg1ATvjTFvICIHfRbBeKig+rdtJ13XMyXQQF0= X-Received: by 2002:a17:906:7195:b0:a30:8523:aa43 with SMTP id h21-20020a170906719500b00a308523aa43mr238932ejk.22.1705920918725; Mon, 22 Jan 2024 02:55:18 -0800 (PST) MIME-Version: 1.0 References: <20240121093653.2890-1-pbhagavatula@marvell.com> In-Reply-To: <20240121093653.2890-1-pbhagavatula@marvell.com> From: =?UTF-8?Q?Juraj_Linke=C5=A1?= Date: Mon, 22 Jan 2024 11:55:07 +0100 Message-ID: Subject: Re: [PATCH 1/2] config/arm: avoid mcpu and march conflicts To: pbhagavatula@marvell.com Cc: jerinj@marvell.com, Ruifeng.Wang@arm.com, nd@arm.com, Bruce Richardson , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Sun, Jan 21, 2024 at 10:37=E2=80=AFAM wrote: > > From: Pavan Nikhilesh > > The compiler options march and mtune are a subset > of mcpu and will lead to conflicts if improper march > is chosen for a given mcpu. > To avoid conflicts, force part number march when > mcpu is available and is supported by the compiler. > > Example: > march =3D armv9-a > mcpu =3D neoverse-n2 > > mcpu supported, march supported > machine_args =3D ['-mcpu=3Dneoverse-n2', '-march=3Darmv9-a'] > > mcpu supported, march not supported > machine_args =3D ['-mcpu=3Dneoverse-n2'] > > mcpu not supported, march supported > machine_args =3D ['-march=3Darmv9-a'] > > mcpu not supported, march not supported > machine_args =3D ['-march=3Darmv8.6-a'] > > Signed-off-by: Pavan Nikhilesh > --- > config/arm/meson.build | 109 +++++++++++++++++++++++++---------------- > 1 file changed, 67 insertions(+), 42 deletions(-) > > diff --git a/config/arm/meson.build b/config/arm/meson.build > index 36f21d2259..8c8cfccca0 100644 > --- a/config/arm/meson.build > +++ b/config/arm/meson.build > @@ -127,21 +128,22 @@ implementer_cavium =3D { > ], > 'part_number_config': { > '0xa1': { > - 'compiler_options': ['-mcpu=3Dthunderxt88'], > + 'mcpu': 'thunderxt88', > 'flags': flags_part_number_thunderx > }, > '0xa2': { > - 'compiler_options': ['-mcpu=3Dthunderxt81'], > + 'mcpu': 'thunderxt81', > 'flags': flags_part_number_thunderx > }, > '0xa3': { > - 'compiler_options': ['-march=3Darmv8-a+crc', '-mcpu=3Dthunde= rxt83'], > + 'mcpu': 'thunderxt83', > + 'compiler_options': ['-march=3Darmv8-a+crc'], Let's unify this with the rest and specify 'march': 'armv8-a+crc' instead of having it under compiler_options. > 'flags': flags_part_number_thunderx > }, > '0xaf': { > 'march': 'armv8.1-a', > 'march_features': ['crc', 'crypto'], > - 'compiler_options': ['-mcpu=3Dthunderx2t99'], > + 'mcpu': 'thunderx2t99', > 'flags': [ > ['RTE_MACHINE', '"thunderx2"'], > ['RTE_ARM_FEATURE_ATOMICS', true], > @@ -153,7 +155,7 @@ implementer_cavium =3D { > '0xb2': { > 'march': 'armv8.2-a', > 'march_features': ['crc', 'crypto', 'lse'], > - 'compiler_options': ['-mcpu=3Docteontx2'], > + 'mcpu': 'octeontx2', > 'flags': [ > ['RTE_MACHINE', '"cn9k"'], > ['RTE_ARM_FEATURE_ATOMICS', true], > @@ -176,7 +178,7 @@ implementer_ampere =3D { > '0x0': { > 'march': 'armv8-a', > 'march_features': ['crc', 'crypto'], > - 'compiler_options': ['-mtune=3Demag'], > + 'mcpu': 'emag', We're changing mtune to mcpu, is this equivalent? > 'flags': [ > ['RTE_MACHINE', '"eMAG"'], > ['RTE_MAX_LCORE', 32], > @@ -186,7 +188,7 @@ implementer_ampere =3D { > '0xac3': { > 'march': 'armv8.6-a', > 'march_features': ['crc', 'crypto'], > - 'compiler_options': ['-mcpu=3Dampere1'], > + 'mcpu': 'ampere1', > 'flags': [ > ['RTE_MACHINE', '"AmpereOne"'], > ['RTE_MAX_LCORE', 320], > @@ -206,7 +208,7 @@ implementer_hisilicon =3D { > '0xd01': { > 'march': 'armv8.2-a', > 'march_features': ['crypto'], > - 'compiler_options': ['-mtune=3Dtsv110'], > + 'mcpu': 'tsv110', > 'flags': [ > ['RTE_MACHINE', '"Kunpeng 920"'], > ['RTE_ARM_FEATURE_ATOMICS', true], > @@ -695,11 +697,23 @@ if update_flags > > machine_args =3D [] # Clear previous machine args > > + candidate_mcpu =3D '' > + support_mcpu =3D false > + if part_number_config.has_key('mcpu') > + mcpu =3D part_number_config['mcpu'] > + if (cc.has_argument('-mcpu=3D' + mcpu)) > + candidate_mcpu =3D mcpu > + support_mcpu =3D true > + endif > + endif > + > # probe supported archs and their features > candidate_march =3D '' > if part_number_config.has_key('march') > - if part_number_config.get('force_march', false) > - candidate_march =3D part_number_config['march'] > + if part_number_config.get('force_march', false) or support_mcpu Instead of using the extra "support_mcpu" variable, we could do the same check as with candidate march (if candidate_mcpu !=3D '', which we actually do below in the last lines of the patch). If I understand the logic correctly, we don't want to do the march fallback if mcpu is specified - either the march works with the given mcpu or we do without it (because we don't actually need it with mcpu). Is that correct? > + if cc.has_argument('-march=3D' + part_number_config['march'= ]) Now that we've added mcpu into the mix, is this still the right condition? Can the below happen? This check finds that machine_args =3D ['-march=3Darmv9-a'] is supported. But taken together with mcpu (machine_args =3D ['-mcpu=3Dneoverse-n2', '-march=3Darmv9-a']), it is not supported? In this case we'll end up with invalid configuration. > + candidate_march =3D part_number_config['march'] > + endif > else > supported_marchs =3D ['armv8.6-a', 'armv8.5-a', 'armv8.4-a',= 'armv8.3-a', > 'armv8.2-a', 'armv8.1-a', 'armv8-a']