[PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Daniel Dragomir]

ARMv8-A supports two main execution states:
  - AArch64 - The 64-bit execution state including exception model,
  memory model, programmers' model and instruction set support for
  that state
  - AArch32 - The 32-bit execution state including exception model,
   memory model, programmers' model and instruction set support for
   that state

This patch adds tunes for 32-bit and 64-bit armv8a platforms.

For AArch32 state, the default tune is aarch32 and include which
    include by default hard float, fp-armv8 floating-point, thumb
    and neon extensions.
    Depending on the features supported by the core, the user can
    select between little or big endian and may choose to enable
    crc and crypto extensions.

For AArch64 state, the default tune is aarch32 and include which
    include just the aarch64 feature.
    Depending on the features supported by the core, the user can
    select between little or big endian and may choose to enable
    crc and crypto extensions.

Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
 meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
 meta/conf/machine/include/arm/arch-armv8a.inc      | 113 +++++++++++++++++++++
 .../conf/machine/include/arm/feature-arm-thumb.inc |   1 +
 meta/conf/machine/include/tune-thunderx.inc        |   2 +-
 meta/conf/machine/qemuarm64.conf                   |   2 +-
 6 files changed, 116 insertions(+), 39 deletions(-)
 delete mode 100644 meta/conf/machine/include/arm/arch-arm64.inc
 delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
 create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc

diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc
deleted file mode 100644
index 9440698..0000000
--- a/meta/conf/machine/include/arm/arch-arm64.inc
+++ /dev/null
@@ -1,36 +0,0 @@
-DEFAULTTUNE ?= "aarch64"
-
-require conf/machine/include/arm/arch-armv7a.inc
-
-TUNEVALID[aarch64] = "Enable instructions for aarch64"
-
-MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
-
-# Little Endian base configs
-AVAILTUNES += "aarch64 aarch64_be"
-ARMPKGARCH_tune-aarch64 ?= "aarch64"
-ARMPKGARCH_tune-aarch64_be ?= "aarch64_be"
-TUNE_FEATURES_tune-aarch64 = "aarch64"
-TUNE_FEATURES_tune-aarch64_be = "${TUNE_FEATURES_tune-aarch64} bigendian"
-BASE_LIB_tune-aarch64 = "lib64"
-BASE_LIB_tune-aarch64_be = "lib64"
-
-PACKAGE_EXTRA_ARCHS_tune-aarch64 = "aarch64"
-PACKAGE_EXTRA_ARCHS_tune-aarch64_be = "aarch64_be"
-
-ARMPKGSFX_ENDIAN_64 = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', '_be', '', d)}"
-TUNE_ARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
-TUNE_PKGARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
-ABIEXTENSION_64 = ""
-TARGET_FPU_64 = ""
-
-# Duplicated from arch-arm.inc
-TUNE_ARCH_32 = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 'arm', d)}"
-TUNE_PKGARCH_32 = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
-ABIEXTENSION_32 = "eabi"
-TARGET_FPU_32 = "${@d.getVar('TUNE_CCARGS_MFLOAT', True) or 'soft'}"
-
-TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_ARCH_64}', '${TUNE_ARCH_32}' ,d)}"
-TUNE_PKGARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}"
-ABIEXTENSION = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${ABIEXTENSION_64}', '${ABIEXTENSION_32}' ,d)}"
-TARGET_FPU = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TARGET_FPU_64}', '${TARGET_FPU_32}' ,d)}"
diff --git a/meta/conf/machine/include/arm/arch-armv8.inc b/meta/conf/machine/include/arm/arch-armv8.inc
deleted file mode 100644
index 5e832fa..0000000
--- a/meta/conf/machine/include/arm/arch-armv8.inc
+++ /dev/null
@@ -1 +0,0 @@
-require conf/machine/include/arm/arch-arm64.inc
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc b/meta/conf/machine/include/arm/arch-armv8a.inc
new file mode 100644
index 0000000..27135e1
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,113 @@
+DEFAULTTUNE ?= "aarch64"
+
+TUNEVALID[aarch32] = "Enable instructions for 32bit state for ARMv8-a (aarch32)"
+TUNEVALID[aarch64] = "Enable instructions for 64bit state for ARMv8-a (aarch64)"
+TUNECONFLICTS[aarch32] = "armv4 armv5 armv6 armv7 armv7a armv7ve"
+
+TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
+ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
+ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
+
+TUNEVALID[crypto] = "Enable ARMv8 crypto extension."
+ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '-crypto', '', d)}"
+ARMPKGSFX_FPU_64 .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '-crypto', '', d)}"
+
+TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
+ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
+
+require conf/machine/include/arm/arch-armv7ve.inc
+
+TUNE_CCARGS .= "${@bb.utils.contains_any('TUNE_FEATURES', [ 'aarch32', 'aarch64' ], bb.utils.contains('TUNE_FEATURES', 'crc', ' -march=armv8-a+crc', ' -march=armv8-a', d), '', d)}"
+TUNE_CCARGS_MFPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', ' fp-armv8', '', d)}"
+TUNE_CCARGS_MFPU .= "${@bb.utils.contains('TUNE_FEATURES', [ 'fp-armv8', 'neon' ], ' neon-fp-armv8', '', d)}"
+TUNE_CCARGS_MFPU .= "${@bb.utils.contains('TUNE_FEATURES', [ 'fp-armv8', 'neon', 'crypto' ], ' crypto-neon-fp-armv8', '', d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
+MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
+
+# Aarch64 Little Endian base configs
+AVAILTUNES += "aarch64 aarch64-crypto aarch64-crc aarch64-crc-crypto"
+ARMPKGARCH_tune-aarch64            ?= "aarch64"
+ARMPKGARCH_tune-aarch64-crypto     ?= "aarch64"
+ARMPKGARCH_tune-aarch64-crc        ?= "aarch64"
+ARMPKGARCH_tune-aarch64-crc-crypto ?= "aarch64"
+TUNE_FEATURES_tune-aarch64            = "aarch64"
+TUNE_FEATURES_tune-aarch64-crypto     = "${TUNE_FEATURES_tune-aarch64} crypto"
+TUNE_FEATURES_tune-aarch64-crc        = "${TUNE_FEATURES_tune-aarch64} crc"
+TUNE_FEATURES_tune-aarch64-crc-crypto = "${TUNE_FEATURES_tune-aarch64-crypto} crc"
+PACKAGE_EXTRA_ARCHS_tune-aarch64            = "aarch64"
+PACKAGE_EXTRA_ARCHS_tune-aarch64-crypto     = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} aarch64-crypto"
+PACKAGE_EXTRA_ARCHS_tune-aarch64-crc        = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} aarch64-crc"
+PACKAGE_EXTRA_ARCHS_tune-aarch64-crc-crypto = "${PACKAGE_EXTRA_ARCHS_tune-aarch64-crypto} aarch64-crc-crypto"
+BASE_LIB_tune-aarch64            = "lib64"
+BASE_LIB_tune-aarch64-crypto     = "lib64"
+BASE_LIB_tune-aarch64-crc        = "lib64"
+BASE_LIB_tune-aarch64-crc-crypto = "lib64"
+
+# Aarch64 Big Endian base configs
+AVAILTUNES += "aarch64_be aarch64_be-crypto aarch64_be-crc aarch64_be-crc-crypto"
+ARMPKGARCH_tune-aarch64_be            ?= "aarch64_be"
+ARMPKGARCH_tune-aarch64_be-crypto     ?= "aarch64_be"
+ARMPKGARCH_tune-aarch64_be-crc        ?= "aarch64_be"
+ARMPKGARCH_tune-aarch64_be-crc-crypto ?= "aarch64_be"
+TUNE_FEATURES_tune-aarch64_be            = "${TUNE_FEATURES_tune-aarch64}            bigendian"
+TUNE_FEATURES_tune-aarch64_be-crypto     = "${TUNE_FEATURES_tune-aarch64-crypto}     bigendian"
+TUNE_FEATURES_tune-aarch64_be-crc        = "${TUNE_FEATURES_tune-aarch64-crc}        bigendian"
+TUNE_FEATURES_tune-aarch64_be-crc-crypto = "${TUNE_FEATURES_tune-aarch64-crc-crypto} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-aarch64_be            = "aarch64_be"
+PACKAGE_EXTRA_ARCHS_tune-aarch64_be-crypto     = "${PACKAGE_EXTRA_ARCHS_tune-aarch64_be} aarch64_be-crypto"
+PACKAGE_EXTRA_ARCHS_tune-aarch64_be-crc        = "${PACKAGE_EXTRA_ARCHS_tune-aarch64_be} aarch64_be-crc"
+PACKAGE_EXTRA_ARCHS_tune-aarch64_be-crc-crypto = "${PACKAGE_EXTRA_ARCHS_tune-aarch64_be-crypto} aarch64_be-crc-crypto"
+BASE_LIB_tune-aarch64_be            = "lib64"
+BASE_LIB_tune-aarch64_be-crypto     = "lib64"
+BASE_LIB_tune-aarch64_be-crc        = "lib64"
+BASE_LIB_tune-aarch64_be-crc-crypto = "lib64"
+
+
+# Aarch32 Little Endian base configs
+AVAILTUNES += "aarch32 aarch32-crypto aarch32-crc aarch32-crc-crypto"
+ARMPKGARCH_tune-aarch32            ?= "aarch32"
+ARMPKGARCH_tune-aarch32-crypto     ?= "aarch32"
+ARMPKGARCH_tune-aarch32-crc        ?= "aarch32"
+ARMPKGARCH_tune-aarch32-crc-crypto ?= "aarch32"
+TUNE_FEATURES_tune-aarch32             = "arm aarch32 thumb neon fp-armv8 callconvention-hard"
+TUNE_FEATURES_tune-aarch32-crypto      = "${TUNE_FEATURES_tune-aarch32} crypto"
+TUNE_FEATURES_tune-aarch32-crc         = "${TUNE_FEATURES_tune-aarch32} crc"
+TUNE_FEATURES_tune-aarch32-crc-crypto  = "${TUNE_FEATURES_tune-aarch32-crypto} crc"
+PACKAGE_EXTRA_ARCHS_tune-aarch32            = "${PACKAGE_EXTRA_ARCHS_tune-armv7vethf} aarch32 aarch32hf aarch32t2hf aarch32hf-fp-armv8 aarch32t2hf-fp-armv8 aarch32hf-neon aarch32t2hf-neon aarch32hf-neon-fp-armv8 aarch32t2hf-neon-fp-armv8"
+PACKAGE_EXTRA_ARCHS_tune-aarch32-crypto     = "${PACKAGE_EXTRA_ARCHS_tune-aarch32} aarch32hf-crypto-neon-fp-armv8 aarch32t2hf-crypto-neon-fp-armv8"
+PACKAGE_EXTRA_ARCHS_tune-aarch32-crc        = "${PACKAGE_EXTRA_ARCHS_tune-aarch32} aarch32hf-crc-neon-fp-armv8 aarch32t2hf-crc-neon-fp-armv8"
+PACKAGE_EXTRA_ARCHS_tune-aarch32-crc-crypto = "${PACKAGE_EXTRA_ARCHS_tune-aarch32-crypto} aarch32hf-crc-crypto-neon-fp-armv8 aarch32t2hf-crc-crypto-neon-fp-armv8"
+
+# Aarch32 Big Endian base configs
+AVAILTUNES += "aarch32b aarch32b-crypto aarch32b-crc aarch32b-crc-crypto"
+ARMPKGARCH_tune-aarch32b            ?= "aarch32"
+ARMPKGARCH_tune-aarch32b-crypto     ?= "aarch32"
+ARMPKGARCH_tune-aarch32b-crc        ?= "aarch32"
+ARMPKGARCH_tune-aarch32b-crc-crypto ?= "aarch32"
+TUNE_FEATURES_tune-aarch32b             = "${TUNE_FEATURES_tune-aarch32}            bigendian"
+TUNE_FEATURES_tune-aarch32b-crypto      = "${TUNE_FEATURES_tune-aarch32-crypto}     bigendian"
+TUNE_FEATURES_tune-aarch32b-crc         = "${TUNE_FEATURES_tune-aarch32-crc}        bigendian"
+TUNE_FEATURES_tune-aarch32b-crc-crypto  = "${TUNE_FEATURES_tune-aarch32-crc-crypto} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-aarch32b            = "${PACKAGE_EXTRA_ARCHS_tune-armv7vethfb} aarch32b aarch32hfb aarch32t2hfb aarch32hfb-fp-armv8 aarch32t2hfb-fp-armv8 aarch32hfb-neon aarch32t2hfb-neon aarch32hfb-neon-fp-armv8 aarch32t2hfb-neon-fp-armv8"
+PACKAGE_EXTRA_ARCHS_tune-aarch32b-crypto     = "${PACKAGE_EXTRA_ARCHS_tune-aarch32b} aarch32hfb-crypto-neon-fp-armv8 aarch32t2hfb-crypto-neon-fp-armv8"
+PACKAGE_EXTRA_ARCHS_tune-aarch32b-crc        = "${PACKAGE_EXTRA_ARCHS_tune-aarch32b} aarch32hfb-crc-neon-fp-armv8 aarch32t2hfb-crc-neon-fp-armv8"
+PACKAGE_EXTRA_ARCHS_tune-aarch32b-crc-crypto = "${PACKAGE_EXTRA_ARCHS_tune-aarch32b-crypto} aarch32hfb-crc-crypto-neon-fp-armv8 aarch32t2hfb-crc-crypto-neon-fp-armv8"
+
+
+ARMPKGSFX_ENDIAN_64 = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', '_be', '', d)}"
+TUNE_ARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
+TUNE_PKGARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}${ARMPKGSFX_FPU_64}"
+ABIEXTENSION_64 = ""
+TARGET_FPU_64 = ""
+
+# Duplicated from arch-arm.inc
+TUNE_ARCH_32 = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 'arm', d)}"
+TUNE_PKGARCH_32 = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
+ABIEXTENSION_32 = "eabi"
+TARGET_FPU_32 = "${@d.getVar('TUNE_CCARGS_MFLOAT', True) or 'soft'}"
+
+TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_ARCH_64}', '${TUNE_ARCH_32}' ,d)}"
+TUNE_PKGARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}"
+ABIEXTENSION = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${ABIEXTENSION_64}', '${ABIEXTENSION_32}' ,d)}"
+TARGET_FPU = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TARGET_FPU_64}', '${TARGET_FPU_32}' ,d)}"
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index 1faebf7..37bed4a 100644
--- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -7,6 +7,7 @@ ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 't2', '', d
 ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7r', 't2', '', d)}"
 ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7m', 't2', '', d)}"
 ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 't2', '', d)}"
+ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 't2', '', d)}"
 
 # If the device supports ARM, then respect ARM_THUMB_OPT (which can be "arm" or "thumb")
 # If the defice doesn't support ARM, then always set "thumb" even when
diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc
index 3d43b0f..4d1247c 100644
--- a/meta/conf/machine/include/tune-thunderx.inc
+++ b/meta/conf/machine/include/tune-thunderx.inc
@@ -1,4 +1,4 @@
-require conf/machine/include/arm/arch-armv8.inc
+require conf/machine/include/arm/arch-armv8a.inc
 
 DEFAULTTUNE ?= "thunderx"
 AVAILTUNES += "thunderx thunderx_be"
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index f59fb15..ff1ff64 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -2,7 +2,7 @@
 #@NAME: generic armv8 machine
 #@DESCRIPTION: Machine configuration for running a generic armv8
 
-require conf/machine/include/arm/arch-armv8.inc
+require conf/machine/include/arm/arch-armv8a.inc
 require conf/machine/include/qemu.inc
 
 KERNEL_IMAGETYPE = "Image"
-- 
1.9.1

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Otavio Salvador]

On Mon, Mar 28, 2016 at 12:29 PM, Daniel Dragomir
<daniel.dragomir@windriver.com> wrote:
> ARMv8-A supports two main execution states:
>   - AArch64 - The 64-bit execution state including exception model,
>   memory model, programmers' model and instruction set support for
>   that state
>   - AArch32 - The 32-bit execution state including exception model,
>    memory model, programmers' model and instruction set support for
>    that state
>
> This patch adds tunes for 32-bit and 64-bit armv8a platforms.
>
> For AArch32 state, the default tune is aarch32 and include which
>     include by default hard float, fp-armv8 floating-point, thumb
>     and neon extensions.
>     Depending on the features supported by the core, the user can
>     select between little or big endian and may choose to enable
>     crc and crypto extensions.
>
> For AArch64 state, the default tune is aarch32 and include which
>     include just the aarch64 feature.
>     Depending on the features supported by the core, the user can
>     select between little or big endian and may choose to enable
>     crc and crypto extensions.
>
> Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>

Just for completeness here, Daniel and I been discussing this (outside
of mailing list) and we agreed that including all the tunes supported
by the ARMv8-A core in a single .inc file makes more sense. As this
tune is still not widely used we think the more invasive change
present in this patch is fine as well.

Khem and Richard, please review and comment on this one.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Phil Blundell]

On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
> For AArch64 state, the default tune is aarch32 and include which
>     include just the aarch64 feature.

I don't really understand what this sentence is trying to say.  Can you
re-phrase it so as to be more accessible to non-experts?

>  meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>  meta/conf/machine/include/arm/arch-armv8.inc       |   1 -

If you are deleting existing files, please mention that in the commit
message.  And in particular, if you are removing a file that supports
generic ARMv8 (if imperfectly) and replacing it with something that is
specific to ARMv8-A, please explain why this is a good thing.

> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"

Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
related to the fpu.  Also, the fact that you need to duplicate both this
and the crypto one for both FPU and FPU_64 seems like an indication that
something elsewhere is misdesigned.

> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"

I don't entirely understand why this one doesn't have an FPU_64
equivalent.  Are you always enabling vfp for A64?

> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"

As previously discussed, I am not wild about "aarch32" as the name of an
override which really means "ARMv8 in AArch32 state".  I know there is a
school of thought that says that the execution state of older cpus is
not AArch32 even if in practice it is indistinguishable, but this
doesn't seem to match either the expectations that a rational user of OE
is likely to have, or the information in the published literature.

> +ARMPKGARCH_tune-aarch64            ?= "aarch64"

This seems a tiny bit short-sighted since presumably there will be an
ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?

> +BASE_LIB_tune-aarch64            = "lib64"

This seems like more a matter of distro policy and I'm not sure it
belongs in a tune file.  If it does then can't you rely on the aarch64
MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
duplicate this for all four of the tunes (and the -be equivalents)?

> +# Duplicated from arch-arm.inc

Please add a comment explaining why you can't include arch-arm.inc.

p.

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Dragomir Daniel]

[-- Attachment #1: Type: text/plain, Size: 5654 bytes --]

Thanks, Phil!
See my answers in-line.

Khem, Richard, Mark, can you please review and comment on this new
version of the patch?

On 03/29/2016 01:10 AM, Phil Blundell wrote:
> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>> For AArch64 state, the default tune is aarch32 and include which
>>      include just the aarch64 feature.
> I don't really understand what this sentence is trying to say.  Can you
> re-phrase it so as to be more accessible to non-experts?

Sorry.

For AArch64 state, the default tune is aarch32 and include just the aarch64 feature.


>>   meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>>   meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
> If you are deleting existing files, please mention that in the commit
> message.  And in particular, if you are removing a file that supports
> generic ARMv8 (if imperfectly) and replacing it with something that is
> specific to ARMv8-A, please explain why this is a good thing.

OK, I'll add a comment.
Before, arch-armv8.inc which apparently add support for generic armv8, only
include arch-arm64.inc, so it's for 64-bit.
But just armv8-A supports 32 and 64 states... armv8-R and armv8-M are just
for 32. So it wasn't generic. Details here:
http://www.arm.com/products/processors/instruction-set-architectures/armv8-r-architecture.php

arch-arm8a.inc add now support for armv8-A processors which support 2 
states:
32-bit and 64-bit states. It makes more sense to have support for both 
states
in the same inc file because both refer to the same arch.

>
>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
> related to the fpu.  Also, the fact that you need to duplicate both this
> and the crypto one for both FPU and FPU_64 seems like an indication that
> something elsewhere is misdesigned.

You're right. I'll add a new suffix variable for crc and crypto witch will
be use for both 32 and 64 tunes.

ARMPKGSFX_EXT - This is the EXTENSIONS specific suffix. The suffix
indicates specific extentions enabled. 'crc' and 'crypto' are defined.
Curently it is used just for armv8a architecture.

>
>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
> I don't entirely understand why this one doesn't have an FPU_64
> equivalent.  Are you always enabling vfp for A64?

Yes. Floating point is enabled by default. From documentation:
"fp- Enable floating-point instructions. This is on by default for all 
possible values for options -marchand -mcpu."
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

>
>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
> As previously discussed, I am not wild about "aarch32" as the name of an
> override which really means "ARMv8 in AArch32 state".  I know there is a
> school of thought that says that the execution state of older cpus is
> not AArch32 even if in practice it is indistinguishable, but this
> doesn't seem to match either the expectations that a rational user of OE
> is likely to have, or the information in the published literature.

I changed armv8a with aarch32 because Khem Raj asked for a previous version
of the patch and in uther discussions related...
http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118904.html

So, you say that we should not use aarch32 and aarch64 for armv8a, but
to use something like armv8a64 and armv8a32?
I have no problem with this, but we need to take a decision agreed by 
everyone.
It's the second time I change the tune names :)

>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
> This seems a tiny bit short-sighted since presumably there will be an
> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?

Maybe with armv8a64 and armv8a32 this will be solved.

>
>> +BASE_LIB_tune-aarch64            = "lib64"
> This seems like more a matter of distro policy and I'm not sure it
> belongs in a tune file.  If it does then can't you rely on the aarch64
> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
> duplicate this for all four of the tunes (and the -be equivalents)?

BASE_LIB is defined also in many other tune files without any overwrites.
It was in aarch64.inc and I simply copied here.

It need to be used with suffix... see in Readme:
BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI.  This is
used in a multilib configuration to place the libraries in the correct,
non-conflicting locations.

And this is how it's used in multilib.conf
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or d.getVar('BASELIB', True)}"

I can use ${BASE_LIB_tune-aarch64} for all the other tunes to be easier
to override.

>> +# Duplicated from arch-arm.inc
> Please add a comment explaining why you can't include arch-arm.inc.

I took the content from arch-arm64.inc and add it here. This duplication
was done in the first commit that add the arch-arm64.inc file.
So, I don't know exactly the reason. Maybe this was discussed on the first
implementation of aarch64 tune made by Mark.

Daniel

> p.
>
>


[-- Attachment #2: Type: text/html, Size: 10123 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 3469 bytes --]


> On Mar 28, 2016, at 3:10 PM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>> For AArch64 state, the default tune is aarch32 and include which
>>    include just the aarch64 feature.
> 
> I don't really understand what this sentence is trying to say.  Can you
> re-phrase it so as to be more accessible to non-experts?
> 
>> meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>> meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
> 
> If you are deleting existing files, please mention that in the commit
> message.  And in particular, if you are removing a file that supports
> generic ARMv8 (if imperfectly) and replacing it with something that is
> specific to ARMv8-A, please explain why this is a good thing.
> 
>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
> 
> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
> related to the fpu.  Also, the fact that you need to duplicate both this
> and the crypto one for both FPU and FPU_64 seems like an indication that
> something elsewhere is misdesigned.
> 
>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
> 
> I don't entirely understand why this one doesn't have an FPU_64
> equivalent.  Are you always enabling vfp for A64?
> 
>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
> 
> As previously discussed, I am not wild about "aarch32" as the name of an
> override which really means "ARMv8 in AArch32 state".  I know there is a
> school of thought that says that the execution state of older cpus is
> not AArch32 even if in practice it is indistinguishable, but this
> doesn't seem to match either the expectations that a rational user of OE
> is likely to have, or the information in the published literature.

Don’t disagree with technical argument I said that previously too. All I am trying
to say is lets take this opportunity to simplify arm tunes starting with armv8
we have this opportunity and what you suggest will keep the thread alive with
prior tunes. With armv8 we should match what we do for x86 and x86_64 ideally.

> 
>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
> 
> This seems a tiny bit short-sighted since presumably there will be an
> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?
> 
>> +BASE_LIB_tune-aarch64            = "lib64"
> 
> This seems like more a matter of distro policy and I'm not sure it
> belongs in a tune file.  If it does then can't you rely on the aarch64
> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
> duplicate this for all four of the tunes (and the -be equivalents)?
> 
>> +# Duplicated from arch-arm.inc
> 
> Please add a comment explaining why you can't include arch-arm.inc.
> 
> p.
> 
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Phil Blundell]

On Tue, 2016-03-29 at 18:59 +0300, Dragomir Daniel wrote:
> 
> arch-arm8a.inc add now support for armv8-A processors which support 2
> states:
> 32-bit and 64-bit states. It makes more sense to have support for
> both states
> in the same inc file because both refer to the same arch. 

OK.  And I assume you feel this is a greater benefit than having the
32-bit ARMv8 bits in a single file that could be shared by ARMv8-R and
ARMv8-M, right?

> So, you say that we should not use aarch32 and aarch64 for armv8a,
> but to use something like armv8a64 and armv8a32?

That would be my preference, but of course it's not my decision to
make.

p.

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Otavio Salvador]

On Tue, Mar 29, 2016 at 2:10 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2016-03-29 at 18:59 +0300, Dragomir Daniel wrote:
>>
>> arch-arm8a.inc add now support for armv8-A processors which support 2
>> states:
>> 32-bit and 64-bit states. It makes more sense to have support for
>> both states
>> in the same inc file because both refer to the same arch.
>
> OK.  And I assume you feel this is a greater benefit than having the
> 32-bit ARMv8 bits in a single file that could be shared by ARMv8-R and
> ARMv8-M, right?

For now, I think it is indeed better. When we add R and M flavours we
can move the 32 bit for another file if we see the need but we ought
to make it simple now.

>> So, you say that we should not use aarch32 and aarch64 for armv8a,
>> but to use something like armv8a64 and armv8a32?
>
> That would be my preference, but of course it's not my decision to
> make.

I like this as well.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Dragomir Daniel]

On 03/29/2016 07:07 PM, Khem Raj wrote:
>> On Mar 28, 2016, at 3:10 PM, Phil Blundell <pb@pbcl.net> wrote:
>>
>> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>>> For AArch64 state, the default tune is aarch32 and include which
>>>     include just the aarch64 feature.
>> I don't really understand what this sentence is trying to say.  Can you
>> re-phrase it so as to be more accessible to non-experts?
>>
>>> meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>>> meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
>> If you are deleting existing files, please mention that in the commit
>> message.  And in particular, if you are removing a file that supports
>> generic ARMv8 (if imperfectly) and replacing it with something that is
>> specific to ARMv8-A, please explain why this is a good thing.
>>
>>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
>> related to the fpu.  Also, the fact that you need to duplicate both this
>> and the crypto one for both FPU and FPU_64 seems like an indication that
>> something elsewhere is misdesigned.
>>
>>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
>> I don't entirely understand why this one doesn't have an FPU_64
>> equivalent.  Are you always enabling vfp for A64?
>>
>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
>> As previously discussed, I am not wild about "aarch32" as the name of an
>> override which really means "ARMv8 in AArch32 state".  I know there is a
>> school of thought that says that the execution state of older cpus is
>> not AArch32 even if in practice it is indistinguishable, but this
>> doesn't seem to match either the expectations that a rational user of OE
>> is likely to have, or the information in the published literature.
> Don’t disagree with technical argument I said that previously too. All I am trying
> to say is lets take this opportunity to simplify arm tunes starting with armv8
> we have this opportunity and what you suggest will keep the thread alive with
> prior tunes. With armv8 we should match what we do for x86 and x86_64 ideally.

We'll need to take a decision on this and continue the work on tunes.

What is the best way to name the armv8a tunes:
aarch32 and aarch64 or armv8a32 and armv8a64?

Who else need to express his opinion about this and make the decision?

Daniel

>
>>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
>> This seems a tiny bit short-sighted since presumably there will be an
>> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?
>>
>>> +BASE_LIB_tune-aarch64            = "lib64"
>> This seems like more a matter of distro policy and I'm not sure it
>> belongs in a tune file.  If it does then can't you rely on the aarch64
>> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
>> duplicate this for all four of the tunes (and the -be equivalents)?
>>
>>> +# Duplicated from arch-arm.inc
>> Please add a comment explaining why you can't include arch-arm.inc.
>>
>> p.
>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 4479 bytes --]


> On Mar 30, 2016, at 9:03 AM, Dragomir Daniel <daniel.dragomir@windriver.com> wrote:
> 
> 
> 
> On 03/29/2016 07:07 PM, Khem Raj wrote:
>>> On Mar 28, 2016, at 3:10 PM, Phil Blundell <pb@pbcl.net> wrote:
>>> 
>>> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>>>> For AArch64 state, the default tune is aarch32 and include which
>>>>    include just the aarch64 feature.
>>> I don't really understand what this sentence is trying to say.  Can you
>>> re-phrase it so as to be more accessible to non-experts?
>>> 
>>>> meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>>>> meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
>>> If you are deleting existing files, please mention that in the commit
>>> message.  And in particular, if you are removing a file that supports
>>> generic ARMv8 (if imperfectly) and replacing it with something that is
>>> specific to ARMv8-A, please explain why this is a good thing.
>>> 
>>>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
>>> related to the fpu.  Also, the fact that you need to duplicate both this
>>> and the crypto one for both FPU and FPU_64 seems like an indication that
>>> something elsewhere is misdesigned.
>>> 
>>>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
>>> I don't entirely understand why this one doesn't have an FPU_64
>>> equivalent.  Are you always enabling vfp for A64?
>>> 
>>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>>>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
>>> As previously discussed, I am not wild about "aarch32" as the name of an
>>> override which really means "ARMv8 in AArch32 state".  I know there is a
>>> school of thought that says that the execution state of older cpus is
>>> not AArch32 even if in practice it is indistinguishable, but this
>>> doesn't seem to match either the expectations that a rational user of OE
>>> is likely to have, or the information in the published literature.
>> Don’t disagree with technical argument I said that previously too. All I am trying
>> to say is lets take this opportunity to simplify arm tunes starting with armv8
>> we have this opportunity and what you suggest will keep the thread alive with
>> prior tunes. With armv8 we should match what we do for x86 and x86_64 ideally.
> 
> We'll need to take a decision on this and continue the work on tunes.
> 
> What is the best way to name the armv8a tunes:
> aarch32 and aarch64 or armv8a32 and armv8a64?

We are catering armv8 here and not 64bit or 32bit arm. Thats the difference.
may be those could be added in a common file?
its fine to call them armv8a32 and armv8a64 it doesnt matter
but break the inclusion of .inc files that will drag it
into pre-armv8 world and define a consistent 32bit tunes
such that when we think armv8, we get three options
aarch64, aarch32, aarch32t2, all the vfp options
may be folder into these three and also neon and others
Can we reach that somehow ?


> 
> Who else need to express his opinion about this and make the decision?
> 
> Daniel
> 
>> 
>>>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
>>> This seems a tiny bit short-sighted since presumably there will be an
>>> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?
>>> 
>>>> +BASE_LIB_tune-aarch64            = "lib64"
>>> This seems like more a matter of distro policy and I'm not sure it
>>> belongs in a tune file.  If it does then can't you rely on the aarch64
>>> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
>>> duplicate this for all four of the tunes (and the -be equivalents)?
>>> 
>>>> +# Duplicated from arch-arm.inc
>>> Please add a comment explaining why you can't include arch-arm.inc.
>>> 
>>> p.
>>> 
>>> 
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Andre McCurdy]

On Wed, Mar 30, 2016 at 9:36 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On Mar 30, 2016, at 9:03 AM, Dragomir Daniel <daniel.dragomir@windriver.com> wrote:
>>
>> On 03/29/2016 07:07 PM, Khem Raj wrote:
>>>> On Mar 28, 2016, at 3:10 PM, Phil Blundell <pb@pbcl.net> wrote:
>>>>
>>>> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>>>>> For AArch64 state, the default tune is aarch32 and include which
>>>>>    include just the aarch64 feature.
>>>> I don't really understand what this sentence is trying to say.  Can you
>>>> re-phrase it so as to be more accessible to non-experts?
>>>>
>>>>> meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>>>>> meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
>>>> If you are deleting existing files, please mention that in the commit
>>>> message.  And in particular, if you are removing a file that supports
>>>> generic ARMv8 (if imperfectly) and replacing it with something that is
>>>> specific to ARMv8-A, please explain why this is a good thing.
>>>>
>>>>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
>>>> related to the fpu.  Also, the fact that you need to duplicate both this
>>>> and the crypto one for both FPU and FPU_64 seems like an indication that
>>>> something elsewhere is misdesigned.
>>>>
>>>>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
>>>> I don't entirely understand why this one doesn't have an FPU_64
>>>> equivalent.  Are you always enabling vfp for A64?
>>>>
>>>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>>>>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
>>>> As previously discussed, I am not wild about "aarch32" as the name of an
>>>> override which really means "ARMv8 in AArch32 state".  I know there is a
>>>> school of thought that says that the execution state of older cpus is
>>>> not AArch32 even if in practice it is indistinguishable, but this
>>>> doesn't seem to match either the expectations that a rational user of OE
>>>> is likely to have, or the information in the published literature.
>>> Don’t disagree with technical argument I said that previously too. All I am trying
>>> to say is lets take this opportunity to simplify arm tunes starting with armv8
>>> we have this opportunity and what you suggest will keep the thread alive with
>>> prior tunes. With armv8 we should match what we do for x86 and x86_64 ideally.
>>
>> We'll need to take a decision on this and continue the work on tunes.
>>
>> What is the best way to name the armv8a tunes:
>> aarch32 and aarch64 or armv8a32 and armv8a64?
>
> We are catering armv8 here and not 64bit or 32bit arm. Thats the difference.
> may be those could be added in a common file?
> its fine to call them armv8a32 and armv8a64 it doesnt matter
> but break the inclusion of .inc files that will drag it
> into pre-armv8 world and define a consistent 32bit tunes
> such that when we think armv8, we get three options
> aarch64, aarch32, aarch32t2,

All armv8a CPUs support Thumb2, so there's no need to distinguish
between aarch32 and aarch32t2.

We've made that mistake historically for armv6 and armv7 but we
shouldn't keep carrying it forward.

> all the vfp options
> may be folder into these three and also neon and others

For most cores from Cortex A9 onwards NEON and VFP are optional, so
hardcoded assumptions won't work.

> Can we reach that somehow ?
>
>
>>
>> Who else need to express his opinion about this and make the decision?
>>
>> Daniel
>>
>>>
>>>>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
>>>> This seems a tiny bit short-sighted since presumably there will be an
>>>> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?
>>>>
>>>>> +BASE_LIB_tune-aarch64            = "lib64"
>>>> This seems like more a matter of distro policy and I'm not sure it
>>>> belongs in a tune file.  If it does then can't you rely on the aarch64
>>>> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
>>>> duplicate this for all four of the tunes (and the -be equivalents)?
>>>>
>>>>> +# Duplicated from arch-arm.inc
>>>> Please add a comment explaining why you can't include arch-arm.inc.
>>>>
>>>> p.
>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5562 bytes --]


> On Mar 30, 2016, at 11:10 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> 
> On Wed, Mar 30, 2016 at 9:36 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>>> On Mar 30, 2016, at 9:03 AM, Dragomir Daniel <daniel.dragomir@windriver.com> wrote:
>>> 
>>> On 03/29/2016 07:07 PM, Khem Raj wrote:
>>>>> On Mar 28, 2016, at 3:10 PM, Phil Blundell <pb@pbcl.net> wrote:
>>>>> 
>>>>> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>>>>>> For AArch64 state, the default tune is aarch32 and include which
>>>>>>   include just the aarch64 feature.
>>>>> I don't really understand what this sentence is trying to say.  Can you
>>>>> re-phrase it so as to be more accessible to non-experts?
>>>>> 
>>>>>> meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>>>>>> meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
>>>>> If you are deleting existing files, please mention that in the commit
>>>>> message.  And in particular, if you are removing a file that supports
>>>>> generic ARMv8 (if imperfectly) and replacing it with something that is
>>>>> specific to ARMv8-A, please explain why this is a good thing.
>>>>> 
>>>>>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>>>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>>>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>>> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
>>>>> related to the fpu.  Also, the fact that you need to duplicate both this
>>>>> and the crypto one for both FPU and FPU_64 seems like an indication that
>>>>> something elsewhere is misdesigned.
>>>>> 
>>>>>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>>>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
>>>>> I don't entirely understand why this one doesn't have an FPU_64
>>>>> equivalent.  Are you always enabling vfp for A64?
>>>>> 
>>>>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>>>>>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
>>>>> As previously discussed, I am not wild about "aarch32" as the name of an
>>>>> override which really means "ARMv8 in AArch32 state".  I know there is a
>>>>> school of thought that says that the execution state of older cpus is
>>>>> not AArch32 even if in practice it is indistinguishable, but this
>>>>> doesn't seem to match either the expectations that a rational user of OE
>>>>> is likely to have, or the information in the published literature.
>>>> Don’t disagree with technical argument I said that previously too. All I am trying
>>>> to say is lets take this opportunity to simplify arm tunes starting with armv8
>>>> we have this opportunity and what you suggest will keep the thread alive with
>>>> prior tunes. With armv8 we should match what we do for x86 and x86_64 ideally.
>>> 
>>> We'll need to take a decision on this and continue the work on tunes.
>>> 
>>> What is the best way to name the armv8a tunes:
>>> aarch32 and aarch64 or armv8a32 and armv8a64?
>> 
>> We are catering armv8 here and not 64bit or 32bit arm. Thats the difference.
>> may be those could be added in a common file?
>> its fine to call them armv8a32 and armv8a64 it doesnt matter
>> but break the inclusion of .inc files that will drag it
>> into pre-armv8 world and define a consistent 32bit tunes
>> such that when we think armv8, we get three options
>> aarch64, aarch32, aarch32t2,
> 
> All armv8a CPUs support Thumb2, so there's no need to distinguish
> between aarch32 and aarch32t2.

I was more talking about execution states than packaging arches.

> 
> We've made that mistake historically for armv6 and armv7 but we
> shouldn't keep carrying it forward.
> 
>> all the vfp options
>> may be folder into these three and also neon and others
> 
> For most cores from Cortex A9 onwards NEON and VFP are optional, so
> hardcoded assumptions won't work.

Is it really ‘onwards’ or just cortexa9 was an exception. Can you
point to some documentation on it ?

> 
>> Can we reach that somehow ?
>> 
>> 
>>> 
>>> Who else need to express his opinion about this and make the decision?
>>> 
>>> Daniel
>>> 
>>>> 
>>>>>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
>>>>> This seems a tiny bit short-sighted since presumably there will be an
>>>>> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?
>>>>> 
>>>>>> +BASE_LIB_tune-aarch64            = "lib64"
>>>>> This seems like more a matter of distro policy and I'm not sure it
>>>>> belongs in a tune file.  If it does then can't you rely on the aarch64
>>>>> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
>>>>> duplicate this for all four of the tunes (and the -be equivalents)?
>>>>> 
>>>>>> +# Duplicated from arch-arm.inc
>>>>> Please add a comment explaining why you can't include arch-arm.inc.
>>>>> 
>>>>> p.
>>>>> 
>>>>> 
>>>>> --
>>>>> _______________________________________________
>>>>> Openembedded-core mailing list
>>>>> Openembedded-core@lists.openembedded.org
>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>> 
>> 
>> 
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Andre McCurdy]

On Wed, Mar 30, 2016 at 11:25 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On Mar 30, 2016, at 11:10 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Wed, Mar 30, 2016 at 9:36 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>>> On Mar 30, 2016, at 9:03 AM, Dragomir Daniel <daniel.dragomir@windriver.com> wrote:
>>>>
>>>> On 03/29/2016 07:07 PM, Khem Raj wrote:
>>>>>> On Mar 28, 2016, at 3:10 PM, Phil Blundell <pb@pbcl.net> wrote:
>>>>>>
>>>>>> On Mon, 2016-03-28 at 18:29 +0300, Daniel Dragomir wrote:
>>>>>>> For AArch64 state, the default tune is aarch32 and include which
>>>>>>>   include just the aarch64 feature.
>>>>>> I don't really understand what this sentence is trying to say.  Can you
>>>>>> re-phrase it so as to be more accessible to non-experts?
>>>>>>
>>>>>>> meta/conf/machine/include/arm/arch-arm64.inc       |  36 -------
>>>>>>> meta/conf/machine/include/arm/arch-armv8.inc       |   1 -
>>>>>> If you are deleting existing files, please mention that in the commit
>>>>>> message.  And in particular, if you are removing a file that supports
>>>>>> generic ARMv8 (if imperfectly) and replacing it with something that is
>>>>>> specific to ARMv8-A, please explain why this is a good thing.
>>>>>>
>>>>>>> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
>>>>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>>>>> +ARMPKGSFX_FPU_64 = "${@bb.utils.contains('TUNE_FEATURES', 'crc', '-crc', '', d)}"
>>>>>> Why is this involved with ARMPKGSFX_FPU?  The crc instructions are not
>>>>>> related to the fpu.  Also, the fact that you need to duplicate both this
>>>>>> and the crypto one for both FPU and FPU_64 seems like an indication that
>>>>>> something elsewhere is misdesigned.
>>>>>>
>>>>>>> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
>>>>>>> +ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'fp-armv8', '-fp-armv8', '', d)}"
>>>>>> I don't entirely understand why this one doesn't have an FPU_64
>>>>>> equivalent.  Are you always enabling vfp for A64?
>>>>>>
>>>>>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch32', 'aarch32:', '' ,d)}"
>>>>>>> +MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', ':aarch64', '' ,d)}"
>>>>>> As previously discussed, I am not wild about "aarch32" as the name of an
>>>>>> override which really means "ARMv8 in AArch32 state".  I know there is a
>>>>>> school of thought that says that the execution state of older cpus is
>>>>>> not AArch32 even if in practice it is indistinguishable, but this
>>>>>> doesn't seem to match either the expectations that a rational user of OE
>>>>>> is likely to have, or the information in the published literature.
>>>>> Don’t disagree with technical argument I said that previously too. All I am trying
>>>>> to say is lets take this opportunity to simplify arm tunes starting with armv8
>>>>> we have this opportunity and what you suggest will keep the thread alive with
>>>>> prior tunes. With armv8 we should match what we do for x86 and x86_64 ideally.
>>>>
>>>> We'll need to take a decision on this and continue the work on tunes.
>>>>
>>>> What is the best way to name the armv8a tunes:
>>>> aarch32 and aarch64 or armv8a32 and armv8a64?
>>>
>>> We are catering armv8 here and not 64bit or 32bit arm. Thats the difference.
>>> may be those could be added in a common file?
>>> its fine to call them armv8a32 and armv8a64 it doesnt matter
>>> but break the inclusion of .inc files that will drag it
>>> into pre-armv8 world and define a consistent 32bit tunes
>>> such that when we think armv8, we get three options
>>> aarch64, aarch32, aarch32t2,
>>
>> All armv8a CPUs support Thumb2, so there's no need to distinguish
>> between aarch32 and aarch32t2.
>
> I was more talking about execution states than packaging arches.

Either way it shouldn't be a concern for the CPU tuning files.
Building Thumb2 for an armv8a CPU is really just an extension of
"optimise for size" and we don't include -Os, -O2, etc options in the
CPU tuning files.

>> We've made that mistake historically for armv6 and armv7 but we
>> shouldn't keep carrying it forward.
>>
>>> all the vfp options
>>> may be folder into these three and also neon and others
>>
>> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>> hardcoded assumptions won't work.
>
> Is it really ‘onwards’ or just cortexa9 was an exception. Can you
> point to some documentation on it ?

Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
ARMv8-A mentions:

"Both floating-point and NEON are required in all standard ARMv8
implementations. However, implementations targeting specialized
markets may support the following combinations:

 - No NEON or floating-point.
 - Full floating-point and SIMD support with exception trapping.
 - Full floating-point and SIMD support without exception trapping.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html

>>
>>> Can we reach that somehow ?
>>>
>>>
>>>>
>>>> Who else need to express his opinion about this and make the decision?
>>>>
>>>> Daniel
>>>>
>>>>>
>>>>>>> +ARMPKGARCH_tune-aarch64            ?= "aarch64"
>>>>>> This seems a tiny bit short-sighted since presumably there will be an
>>>>>> ARMv9 (or ARMv8.2) at some point.  What will ARMPKGARCH for A64 be then?
>>>>>>
>>>>>>> +BASE_LIB_tune-aarch64            = "lib64"
>>>>>> This seems like more a matter of distro policy and I'm not sure it
>>>>>> belongs in a tune file.  If it does then can't you rely on the aarch64
>>>>>> MACHINEOVERRIDE and just write "BASE_LIB_aarch64" rather than having to
>>>>>> duplicate this for all four of the tunes (and the -be equivalents)?
>>>>>>
>>>>>>> +# Duplicated from arch-arm.inc
>>>>>> Please add a comment explaining why you can't include arch-arm.inc.
>>>>>>
>>>>>> p.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> Openembedded-core mailing list
>>>>>> Openembedded-core@lists.openembedded.org
>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>
>>>
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Phil Blundell]

On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
> Either way it shouldn't be a concern for the CPU tuning files.
> Building Thumb2 for an armv8a CPU is really just an extension of
> "optimise for size" and we don't include -Os, -O2, etc options in the
> CPU tuning files.

Yes, agreed.  In principle there's no reason that the compiler couldn't
choose between A32 and T32 instruction sets dynamically for each
compilation unit (or each function) according to which it thinks would
give the better result.  And from the user's point of view, the outcome
should be equivalent apart from minor performance differences.

> >> For most cores from Cortex A9 onwards NEON and VFP are optional, so
> >> hardcoded assumptions won't work.

> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
> ARMv8-A mentions:
> 
> "Both floating-point and NEON are required in all standard ARMv8
> implementations. However, implementations targeting specialized
> markets may support the following combinations:
> 
>  - No NEON or floating-point.
>  - Full floating-point and SIMD support with exception trapping.
>  - Full floating-point and SIMD support without exception trapping.

Is there any evidence that anyone is actually building ARMv8-A (as
opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
fairly clear indication that such cores do exist and are likely to be
used with OE, I think we should not complicate the tuning files with
support for such things.  Anybody who wants them can always add
appropriate tunes later, either in oe-core or in their own layer.

p.

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]


> On Mar 30, 2016, at 11:53 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> 
>> 
>> Is it really ‘onwards’ or just cortexa9 was an exception. Can you
>> point to some documentation on it ?
> 
> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
> ARMv8-A mentions:
> 
> "Both floating-point and NEON are required in all standard ARMv8
> implementations. However, implementations targeting specialized
> markets may support the following combinations:
> 
> - No NEON or floating-point.
> - Full floating-point and SIMD support with exception trapping.
> - Full floating-point and SIMD support without exception trapping.
> 

this means nothing changes for ARM ABIs from v7 to v8 question is do we care
enough for these offshoots.

> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html
> 
> 



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]


> On Mar 30, 2016, at 3:46 PM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
>> Either way it shouldn't be a concern for the CPU tuning files.
>> Building Thumb2 for an armv8a CPU is really just an extension of
>> "optimise for size" and we don't include -Os, -O2, etc options in the
>> CPU tuning files.
> 
> Yes, agreed.  In principle there's no reason that the compiler couldn't
> choose between A32 and T32 instruction sets dynamically for each
> compilation unit (or each function) according to which it thinks would
> give the better result.  And from the user's point of view, the outcome
> should be equivalent apart from minor performance differences.

yes I think thumb2 on aarch32 may be controlled via a global configuration metadata
like distro feature or some such.

> 
>>>> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>>>> hardcoded assumptions won't work.
> 
>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
>> ARMv8-A mentions:
>> 
>> "Both floating-point and NEON are required in all standard ARMv8
>> implementations. However, implementations targeting specialized
>> markets may support the following combinations:
>> 
>> - No NEON or floating-point.
>> - Full floating-point and SIMD support with exception trapping.
>> - Full floating-point and SIMD support without exception trapping.
> 
> Is there any evidence that anyone is actually building ARMv8-A (as
> opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
> fairly clear indication that such cores do exist and are likely to be
> used with OE, I think we should not complicate the tuning files with
> support for such things.  Anybody who wants them can always add
> appropriate tunes later, either in oe-core or in their own layer.
> 

agreed.

> p.
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Andre McCurdy]

On Wed, Mar 30, 2016 at 3:46 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
>> Either way it shouldn't be a concern for the CPU tuning files.
>> Building Thumb2 for an armv8a CPU is really just an extension of
>> "optimise for size" and we don't include -Os, -O2, etc options in the
>> CPU tuning files.
>
> Yes, agreed.  In principle there's no reason that the compiler couldn't
> choose between A32 and T32 instruction sets dynamically for each
> compilation unit (or each function) according to which it thinks would
> give the better result.  And from the user's point of view, the outcome
> should be equivalent apart from minor performance differences.
>
>> >> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>> >> hardcoded assumptions won't work.
>
>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
>> ARMv8-A mentions:
>>
>> "Both floating-point and NEON are required in all standard ARMv8
>> implementations. However, implementations targeting specialized
>> markets may support the following combinations:
>>
>>  - No NEON or floating-point.
>>  - Full floating-point and SIMD support with exception trapping.
>>  - Full floating-point and SIMD support without exception trapping.
>
> Is there any evidence that anyone is actually building ARMv8-A (as
> opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
> fairly clear indication that such cores do exist and are likely to be
> used with OE, I think we should not complicate the tuning files with
> support for such things.  Anybody who wants them can always add
> appropriate tunes later, either in oe-core or in their own layer.

I can't find any evidence of real ARMv8-A cores without NEON or VFP,
so if any "new approach" to ARM CPU tuning files is limited to armv8a
then hardcoding support for NEON and VFP is probably going to work out
OK (at least until someone wants support for the half-precision
floating point extensions added in ARMv8.2-A).

Personally though, I'd like to see a comprehensive cleanup and
restructuring which could be applied to all ARM tuning files,
including armv7a where NEON certainly is optional in the real world.

> p.
>
>

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Otavio Salvador]

Hello folks,

On Wed, Mar 30, 2016 at 8:59 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Wed, Mar 30, 2016 at 3:46 PM, Phil Blundell <pb@pbcl.net> wrote:
>> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
>>> Either way it shouldn't be a concern for the CPU tuning files.
>>> Building Thumb2 for an armv8a CPU is really just an extension of
>>> "optimise for size" and we don't include -Os, -O2, etc options in the
>>> CPU tuning files.
>>
>> Yes, agreed.  In principle there's no reason that the compiler couldn't
>> choose between A32 and T32 instruction sets dynamically for each
>> compilation unit (or each function) according to which it thinks would
>> give the better result.  And from the user's point of view, the outcome
>> should be equivalent apart from minor performance differences.
>>
>>> >> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>>> >> hardcoded assumptions won't work.
>>
>>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
>>> ARMv8-A mentions:
>>>
>>> "Both floating-point and NEON are required in all standard ARMv8
>>> implementations. However, implementations targeting specialized
>>> markets may support the following combinations:
>>>
>>>  - No NEON or floating-point.
>>>  - Full floating-point and SIMD support with exception trapping.
>>>  - Full floating-point and SIMD support without exception trapping.
>>
>> Is there any evidence that anyone is actually building ARMv8-A (as
>> opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
>> fairly clear indication that such cores do exist and are likely to be
>> used with OE, I think we should not complicate the tuning files with
>> support for such things.  Anybody who wants them can always add
>> appropriate tunes later, either in oe-core or in their own layer.
>
> I can't find any evidence of real ARMv8-A cores without NEON or VFP,
> so if any "new approach" to ARM CPU tuning files is limited to armv8a
> then hardcoding support for NEON and VFP is probably going to work out
> OK (at least until someone wants support for the half-precision
> floating point extensions added in ARMv8.2-A).
>
> Personally though, I'd like to see a comprehensive cleanup and
> restructuring which could be applied to all ARM tuning files,
> including armv7a where NEON certainly is optional in the real world.

Could you, Phil and Khem summarize the remarks in a succinct way? To
be honest I am a little lost on what changes you all are expecting on
top of the last patch version.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Andre McCurdy]

On Fri, Apr 1, 2016 at 12:13 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> Hello folks,
>
> On Wed, Mar 30, 2016 at 8:59 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Wed, Mar 30, 2016 at 3:46 PM, Phil Blundell <pb@pbcl.net> wrote:
>>> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
>>>> Either way it shouldn't be a concern for the CPU tuning files.
>>>> Building Thumb2 for an armv8a CPU is really just an extension of
>>>> "optimise for size" and we don't include -Os, -O2, etc options in the
>>>> CPU tuning files.
>>>
>>> Yes, agreed.  In principle there's no reason that the compiler couldn't
>>> choose between A32 and T32 instruction sets dynamically for each
>>> compilation unit (or each function) according to which it thinks would
>>> give the better result.  And from the user's point of view, the outcome
>>> should be equivalent apart from minor performance differences.
>>>
>>>> >> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>>>> >> hardcoded assumptions won't work.
>>>
>>>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
>>>> ARMv8-A mentions:
>>>>
>>>> "Both floating-point and NEON are required in all standard ARMv8
>>>> implementations. However, implementations targeting specialized
>>>> markets may support the following combinations:
>>>>
>>>>  - No NEON or floating-point.
>>>>  - Full floating-point and SIMD support with exception trapping.
>>>>  - Full floating-point and SIMD support without exception trapping.
>>>
>>> Is there any evidence that anyone is actually building ARMv8-A (as
>>> opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
>>> fairly clear indication that such cores do exist and are likely to be
>>> used with OE, I think we should not complicate the tuning files with
>>> support for such things.  Anybody who wants them can always add
>>> appropriate tunes later, either in oe-core or in their own layer.
>>
>> I can't find any evidence of real ARMv8-A cores without NEON or VFP,
>> so if any "new approach" to ARM CPU tuning files is limited to armv8a
>> then hardcoding support for NEON and VFP is probably going to work out
>> OK (at least until someone wants support for the half-precision
>> floating point extensions added in ARMv8.2-A).
>>
>> Personally though, I'd like to see a comprehensive cleanup and
>> restructuring which could be applied to all ARM tuning files,
>> including armv7a where NEON certainly is optional in the real world.
>
> Could you, Phil and Khem summarize the remarks in a succinct way? To
> be honest I am a little lost on what changes you all are expecting on
> top of the last patch version.

I think the last comment from Richard was:

"I'm planning to drop the patch triggering this from -next and
defer it until 2.2. The discussions can happen in the meantime to get a
patchset we're all happy with."

So I don't think anything is expected for 2.1.

The floor is still open for discussion for 2.2. One initial question
seems to be whether we're aiming for a point solution for armv8a or a
wider ranging cleanup?

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]


> On Apr 1, 2016, at 3:03 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> 
> On Fri, Apr 1, 2016 at 12:13 PM, Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
>> Hello folks,
>> 
>> On Wed, Mar 30, 2016 at 8:59 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> On Wed, Mar 30, 2016 at 3:46 PM, Phil Blundell <pb@pbcl.net> wrote:
>>>> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote:
>>>>> Either way it shouldn't be a concern for the CPU tuning files.
>>>>> Building Thumb2 for an armv8a CPU is really just an extension of
>>>>> "optimise for size" and we don't include -Os, -O2, etc options in the
>>>>> CPU tuning files.
>>>> 
>>>> Yes, agreed.  In principle there's no reason that the compiler couldn't
>>>> choose between A32 and T32 instruction sets dynamically for each
>>>> compilation unit (or each function) according to which it thinks would
>>>> give the better result.  And from the user's point of view, the outcome
>>>> should be equivalent apart from minor performance differences.
>>>> 
>>>>>>> For most cores from Cortex A9 onwards NEON and VFP are optional, so
>>>>>>> hardcoded assumptions won't work.
>>>> 
>>>>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for
>>>>> ARMv8-A mentions:
>>>>> 
>>>>> "Both floating-point and NEON are required in all standard ARMv8
>>>>> implementations. However, implementations targeting specialized
>>>>> markets may support the following combinations:
>>>>> 
>>>>> - No NEON or floating-point.
>>>>> - Full floating-point and SIMD support with exception trapping.
>>>>> - Full floating-point and SIMD support without exception trapping.
>>>> 
>>>> Is there any evidence that anyone is actually building ARMv8-A (as
>>>> opposed to -R or -M) cores that lack VFP and/or NEON?  Unless there is a
>>>> fairly clear indication that such cores do exist and are likely to be
>>>> used with OE, I think we should not complicate the tuning files with
>>>> support for such things.  Anybody who wants them can always add
>>>> appropriate tunes later, either in oe-core or in their own layer.
>>> 
>>> I can't find any evidence of real ARMv8-A cores without NEON or VFP,
>>> so if any "new approach" to ARM CPU tuning files is limited to armv8a
>>> then hardcoding support for NEON and VFP is probably going to work out
>>> OK (at least until someone wants support for the half-precision
>>> floating point extensions added in ARMv8.2-A).
>>> 
>>> Personally though, I'd like to see a comprehensive cleanup and
>>> restructuring which could be applied to all ARM tuning files,
>>> including armv7a where NEON certainly is optional in the real world.
>> 
>> Could you, Phil and Khem summarize the remarks in a succinct way? To
>> be honest I am a little lost on what changes you all are expecting on
>> top of the last patch version.
> 
> I think the last comment from Richard was:
> 
> "I'm planning to drop the patch triggering this from -next and
> defer it until 2.2. The discussions can happen in the meantime to get a
> patchset we're all happy with."
> 
> So I don't think anything is expected for 2.1.
> 
> The floor is still open for discussion for 2.2. One initial question
> seems to be whether we're aiming for a point solution for armv8a or a
> wider ranging cleanup?

I would support the latter. Andre, since you have mentioned it earlier
would you mind opening a bugzilla entry for cleanup for 2.2 ?

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] ARMv8-A: Add tune for AArch32 state and AArch64 state

[Otavio Salvador]

On Fri, Apr 1, 2016 at 7:03 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> The floor is still open for discussion for 2.2. One initial question
> seems to be whether we're aiming for a point solution for armv8a or a
> wider ranging cleanup?

I think we ought to work on a solution for armv8a and basing on that
we can clean up the other things.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750