[OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES

[Herve Jourdain]

Hi,

Just my 2 cents about this.
armv8-a is the architecture of the arm core, while aarch64/aarch32 is the
execution mode on said architecture.
So I believe that we should have overrides for BOTH the architecture and the
execution mode, as you can have armv8-a executing in 32 bits mode - and btw,
the instruction set in 32 bits mode is not exactly the same as armv7-ve, so
in terms of optimization it does help to know you're running on an armv8-a
architecture, even if it's in 32 bits mode.
There was no such problem before armv8-a architecture, since all previous
architectures were running in 32 bits mode only. Armv8-a changes that as
it's a "hybrid", with support for both aarch64 and aarch32.
I expect later arch to support only aarch64.

There is also an additional thing to consider, there is not just one armv8-a
profiles, there already are several, and they shall all be taken into
account.
I believe that at this time, the valid ones are armv8.0-a, armv8.1-a,
armv8.2-a, armv8.3-a  and armv8.4-a.

And let me answer before someone asks, yes the gcc compiler DOES provide
compiler options for all those architectures, with those exact names -
except armv8.0-a is just named armv8-a (-march=armv8-a or
-march=armv8.[1,2,3,4]-a).
So it just makes sense to support them all.

So overall, I believe we should support all those arm v8 architectures, and
add the corresponding override to the cpu definition files (for instance, as
Peter mentioned, cortex-a53 is an armv8.0-a. But a cortex-a55 or cortex-a75
would be an armv8.2-a).

Finally, the arm architecture is slightly more complex than just armv8.x-a,
since the support for "features" is optional. So at least "crc" and "crypto"
features should be added, in order to have a "comprehensive" view of the
armv8 architecture. And yes, the "features" are also supported by the gcc
compiler.
So the arm architecture would really be fully defined by
armv8.x-a+[no]crc+[no]crypto, depending on the underlying SoC and what they
implemented or not as optional features. And this is probably what should
end up going into the tune-cortexa53.inc and others (and should be
override-able, since again not all cortexa53 are created the same).

Cheers,
Herve

-----Original Message-----
From: openembedded-core-bounces at lists.openembedded.org
<openembedded-core-bounces at lists.openembedded.org> On Behalf Of Peter
Kjellerstedt
Sent: 03 March 2020 13:00
To: Junling Zheng <zhengjunling at huawei.com>; Khem Raj <raj.khem at gmail.com>;
openembedded-core at lists.openembedded.org
Cc: wangnan0 at huawei.com
Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
MACHINEOVERRIDES

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org 
> <openembedded-core- bounces at lists.openembedded.org> On Behalf Of 
> Junling Zheng
> Sent: den 3 mars 2020 04:11
> To: Khem Raj <raj.khem at gmail.com>; openembedded- 
> core at lists.openembedded.org
> Cc: wangnan0 at huawei.com
> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 
> in MACHINEOVERRIDES
> 
> On 2020/3/3 2:29, Khem Raj wrote:
> >
> >
> > On 3/2/20 9:11 AM, Junling Zheng wrote:
> >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES 
> >> with "aarch64:", which has the higher priority than
TRANSLATED_TARGET_ARCH.
> >> So, for aarch64 big endian, the variable '<foo>_aarch64' will 
> >> override not only '<foo>', but also '<foo>_aarch64-be', thus we 
> >> will get an incorrect variable.
> >>
> >> Signed-off-by: Junling Zheng <zhengjunling at huawei.com>
> >> ---
> >>   meta/conf/machine/include/arm/arch-arm64.inc | 2 --
> >>   1 file changed, 2 deletions(-)
> >>
> >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc
> b/meta/conf/machine/include/arm/arch-arm64.inc
> >> index 53f4566815..32294bd218 100644
> >> --- a/meta/conf/machine/include/arm/arch-arm64.inc
> >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc
> >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc
> >>     TUNEVALID[aarch64] = "Enable instructions for aarch64"
> >>   -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',
'aarch64', 'aarch64:', '' ,d)}"
> >> -
> >
> > if its removed here, where is it being added for other machines,
> question is, should we treat aarch64 as LE equivalent of aarch64_be
> > or should be treated as common aarch64 and a new define like 
> > aarch64_le
> defined.
> >
> 
> Currently, for arm64, we have aarch64_be to represent big endian, but 
> no overrides to represent little endian only.
> 
> So, IMO, we should treat aarch64 as little enaian only, like arm and 
> armeb.
> 
> >>   # Little Endian base configs
> >>   AVAILTUNES += "aarch64 aarch64_be"
> >>   ARMPKGARCH_tune-aarch64 ?= "aarch64"

Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or
similar. This is how it is done for the armv7* based chips. E.g., I would
expect to see tune-cortexa53.inc have:

MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53',
'armv8a:', '' ,d)}"

Which corresponds to how it is done for armv7*.

At least we currently rely on being able to do, e.g.:

COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve"

and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable
substitute.

//Peter

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core at lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core