Commit Graph

46 Commits

Author SHA1 Message Date
Vincent Fazio
2bd0431baf arch/Config.in.x86: consolidate Geode CPU targets
Since its introduction in 7d8a59b40, the BR2_x86_geode CPU target has
pointed to GCC -march=geode which targets AMD Geode processors [0].

This arch tuning enables MMX and 3DNow! extensions in GCC but these are
not currently reflected in the selected flags by BR2_x86_geode.

This is likely due to the confusing naming and history of "Geode".

The AMD Geode can trace its origins back to the Cyrix MediaGXm [1] and
then to the NSC Geode GXm/GXLV/GX1/GX2 [2]. All of these processors have
MMX instruction support listed in their datasheets. The NSC GX2 was the
first in the series to enable 3DNow!.

When 7fed07d3a4 introduced BR2_X86_CPU_HAS_MMX, Geode was skipped
presumably because it wasn't clear that the target is AMD Geode and
because the Wikipedia documentation for Geode is incomplete [2] with
regards to supported instructions as they all support MMX.

When f6cd56b9ce introduced BR2_X86_CPU_HAS_3DNOW, Geode was skipped
presumably for similar reasons.

Note: the in-tree olpc_xo1_defconfig uses BR2_x86_geode which is fine
as this hardware uses the AMD Geode [3].

Make it more clear that the target is AMD Geode by renaming the Kconfig
menu option and add both MMX and 3DNow! flags to BR2_x86_geode.

This also means that BR2_x86_geode_mmx is no longer needed, and can be
removed. No legacy handling is needed since BR2_x86_geode_mmx has
never been part of any release.

[0]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/geode.md;;hb=HEAD
[1]: https://en.wikipedia.org/wiki/MediaGX#MediaGXm
[2]: https://en.wikipedia.org/wiki/Geode_%28processor%29
[3]: https://wiki.laptop.org/go/Hardware_specification

Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-08-01 23:16:02 +02:00
Vincent Fazio
22e476d788 arch/Config.in.x86: add Intel and AMD GCC targets
Sync the Intel and AMD CPU target list with GCC 13.

Multiple references are used for flags and synonyms [0] [1] [2] [3].

For Intel:
  Add Ivy Bridge, Sierra Forest, Grand Ridge, Knights Landing, Knights
  Mill, Granite Rapids, and Granite Rapids-D.

  The Sapphire Rapids CPU target supports Emerald Rapids.
  The Alder Lake CPU target supports Raptor Lake and Meteor Lake.

  Note: Knights Landing/Mills are based on Xeon Phi and do support
  some AVX512 extensions, but not the full subset required by
  BR2_X86_CPU_HAS_AVX512

For AMD:
  Add Bobcat, Bulldozer, Piledriver, Excavator, and Zen 1-4.

Add a comment to BR2_X86_CPU_HAS_AVX512 to explain the expected
extensions supported by the CPU. This flag was first selected by
skylake-avx512 and encompasses what appears to be a standard subset
across CPUs [3] and chapter 3 of the x86-64 psABI [4]:
  AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

CPUs selecting this flag should, at a minimum, support this subset of
AVX512 extensions.

[0]: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html
[1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/i386/i386.h;hb=refs/tags/releases/gcc-13.2.0
[2]: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/common/config/i386/i386-common.cc;hb=refs/tags/releases/gcc-13.2.0
[3]: https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
[4]: https://gitlab.com/x86-psABIs/x86-64-ABI/-/raw/master/x86-64-ABI/low-level-sys-info.tex

Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-08-01 00:14:50 +02:00
Vincent Fazio
f82a65b15b arch/Config.in.x86: drop AVX512 from alderlake
Alder Lake CPUs have AVX512 support disabled [0].

To prevent potential issues, remove the AVX512 support advertisement.

This puts Buildroot inline with the GCC options [1].

[0]: https://www.intel.com/content/www/us/en/support/articles/000089918/processors.html
[1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

Fixes: e7b94130 ("arch/Config.in.x86: add sapphirerapids, alderlake, rocketlake")
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-07-27 23:13:36 +02:00
Cherniaev Andrei
09d1bbde47 arch/Config.in.x86: add MMX instruction set capability for Geode CPU
Currently, there is no MMX support for modern GEODE processors in Buildroot.
Yet, some packages like ffmpeg can leverage it when the package is built.

Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2023-07-23 15:48:43 +02:00
Romain Naour
92357f4cbe arch/Config.in.x86: fix bonnell typo
Commit [1] added several x86 cpu variant and introduced a typo
(bonnel) on bonnell cpu.

Rename BR2_x86_bonnel to BR2_x86_bonnell without legacy
handling since it never worked.

Fixes:
http://autobuild.buildroot.net/results/2418106d30e07cf09834941e610c75dde78816d2/

[1] 653fa001f3

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-05-15 20:10:35 +02:00
Thomas De Schampheleire
dd8a410eaf core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH
The variable 'KERNEL_ARCH' is actually a normalized version of
'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just
as all powerpc variants become 'powerpc'.

It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically
the first place where support for a new architecture is added, and thus is
the entity that defines the normalized name.

However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture
used by the kernel', which need not be exactly the same as 'the normalized
name for a certain arch'. In particular, for cases where a 64-bit
architecture is running a 64-bit kernel but 32-bit userspace. Examples
include:
    * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace
    * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace

In such cases, the 'architecture used by the kernel' needs to refer to the
64-bit name (aarch64, x86_64), whereas all userspace applications need to
refer the, potentially normalized, 32-bit name.

This means that there need to be two different variables:

KERNEL_ARCH:     the architecture used by the kernel
NORMALIZED_ARCH: the normalized name for the current userspace architecture

At this moment, both will actually have the same content. But a subsequent
patch will add basic support for situations described above, in which
KERNEL_ARCH may become overwritten to the 64-bit architecture, while
NORMALIZED_ARCH needs to remain the same (32-bit) case.

This commit replaces use of KERNEL_ARCH where actually the userspace arch is
needed.  Places that use KERNEL_ARCH in combination with building of kernel
modules are not touched.
There may be cases where a package builds both a kernel module as userspace,
in which case it may need to know about both KERNEL_ARCH and
NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on
a per-need basis.

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-02-08 21:20:23 +01:00
Thomas De Schampheleire
cf198e2299 arch: move definition of KERNEL_ARCH to Config.in.<arch> files
Similar to other arch-specific strings, the 'KERNEL_ARCH' variable can be
determined from Config.in.<arch> files.

Besides aligning with similar strings, this also means simplification: the
big 'sed' covers several architectures not even supported by Buildroot.

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-02-08 20:55:36 +01:00
Thomas Petazzoni
206ce35161 arch/Config.in.x86: indicate how the CPU variants are ordered
They are loosely ordered according to the ordering of the gcc
documentation. It is not entirely correct as the generic x86-64,
x86-64-v2, x86-64-v3 and x86-64-v4 are listed before i386 in the gcc
documentation, but this nevertheless gives a good explanation for the
overall ordering of the list.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:33 +01:00
Thomas Petazzoni
e7b9413056 arch/Config.in.x86: add sapphirerapids, alderlake, rocketlake
These were added in gcc 11.x.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:30 +01:00
Thomas Petazzoni
0b84dcf968 arch/Config.in.x86: add cooperlake CPU variant
It was added in gcc 10.x.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:28 +01:00
Thomas Petazzoni
ffcefb3a75 arch/Config.in.x86: add goldmont, goldmont-plus, tremont, cascadelake, tigerlake CPU variants
These were added in gcc 9.x. The goldmont, goldmont-plus and tremont
are for the low-power CPUs. While cascadelake and tigerlake are for
the high-end ones.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:26 +01:00
Thomas Petazzoni
86a70de48e arch/Config.in.x86: add cannonlake, icelake-client, icelake-server CPU variants
These were added in gcc 8.x.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:24 +01:00
Thomas Petazzoni
4fa073c65f arch/Config.in.x86: x86-64-v4 implies AVX512
Now that we have BR2_X86_CPU_HAS_AVX512, we can use it to fix the
x86-64-v4 definition, which implies AVX512 support according to
https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:17 +01:00
Thomas Petazzoni
4c0088718e arch/Config.in.x86: add skylake CPU variants
Both skylake and skylake-avx512 were added in gcc 6.x. According to
https://en.wikipedia.org/wiki/Skylake_(microarchitecture) the early
Skylake processors indeed did not have AVX512 support, while the later
ones did, hence the separate gcc options.

Due to this being the first CPU we support with AVX512, this commit
adds BR2_X86_CPU_HAS_AVX512.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:14 +01:00
Thomas Petazzoni
3702977799 arch/Config.in.x86: add broadwell Intel CPU variant
It was added in gcc 4.9.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:12 +01:00
Thomas Petazzoni
1a21705e73 arch/Config.in.x86: westmere and silvermont were added in gcc 4.9
These were added in gcc commit
d3c11974032e21121a051d423a1d71097edf752f ("Use proper Intel processor
names for -march=/-mtune=") which was merged in gcc 4.9.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:10 +01:00
Thomas Petazzoni
653fa001f3 arch/Config.in.x86: add "newer" names for several Intel x86 CPU variants
In gcc commit d3c11974032e21121a051d423a1d71097edf752f ("Use proper
Intel processor names for -march=/-mtune="), which was merged in gcc
4.9, the following replacements were made:

 * corei7     -> nehalem
 * corei7-avx -> sandybridge
 * core-avx-i -> ivybridge
 * core-avx2  -> haswell
 * atom       -> bonnel
 * slm        -> silvermont

So this commit marks the Buildroot options BR2_x86_corei7,
BR2_x86_corei7_avx, BR2_x86_core_avx2 and BR2_x86_atom as deprecated,
and adds the four corresponding options with the newer names.

Note that the older options are still kept because the new option
names are only supported starting gcc 4.9, and we theoretically still
supports targets gcc as old as gcc 4.3.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:08 +01:00
Thomas Petazzoni
73d135a695 arch/Config.in.x86: drastically simplify the BR2_ARCH definition
The BR2_ARCH definition is like this:

 * i486 for the i486 platform
 * i586 for a small number of platforms
 * i686 for all other x86 platforms when used in 32-bit, but we
   enumerate their entire list
 * x86_64 for all x86 64-bit platforms

The list for i686 is long and needs to be extended everytime a new
platform is added, with no added value.

So this commit simplifies that by replacing this long list with just:

   default "i686"	  if BR2_i386

This works because Kconfig guarantees us that if an i386 platform
matches an earlier case (i486 or one of the i586 platforms), the i486
and i586 earlier in the list will match.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-25 08:41:06 +01:00
Thomas Petazzoni
eeace1cc13 arch/Config.in.x86: add support for x86-64-v2, x86-64-v3, x86-64-v4
In the face of the vast amount of x86-64 CPU architecture variants,
Linux distributions have worked together to define "micro-architecture
levels" in the x86-64 psABI, called x86-64-v2, x86-64-v3 and
x86-64-v4. They standardize a set of CPU features, and GCC since its
version 11.x has support for these micro-architecture levels as
-march= options.

It makes sense to support them in Buildroot, especially for those who
want to build toolchains that aim at targeting a reasonably broad
family of x86-64 processors.

It only really makes sense to use as 64-bit CPUs, and not as 32-bit
ones, so we guard them behind BR2_x86_64.

More details:

 https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex
 https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
 https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-x86-64-Feature-Levels
 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=59482fa1e7243bd905c7e27c92ae2b89c79fff87

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
  - they are x86-64-only CPUs
  - add gcc commit URL
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-09 11:30:26 +01:00
Thomas Petazzoni
d6ce2a1681 arch/Config.in.x86: add option for -march=x86-64
We already have support for a wide range of x86-64 CPUs, but we don't
have any option to build for the most generic possible x86-64 CPU, as
made available by the -march=x86-64 GCC option.

This commit makes this option available in Buildroot.

It only really makes sense to use as a 64-bit CPU, and not as a 32-bit
one, so we guard it behind BR2_x86_64.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: it's an x86-64-only CPU]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-09 11:30:26 +01:00
Nicolas Robin
f6cd56b9ce arch/x86: adds BR2_X86_CPU_HAS_3DNOW flag
Signed-off-by: Nicolas Robin <nrosfs@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-15 21:47:50 +02:00
Esben Haabendal
97651ce275 arch: Add support for Westmere targets
The westmere line of x86_64 targets lies between nehalem (corei7) and
sandybridge (corei7-avx).  Allowing use of -march=westmere enables use of
AES instruction set on these targets.

Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-06-13 21:09:51 +02:00
Esben Haabendal
498a1fabe8 arch: Fix typo breaking use of core-avx2 arch
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-06-08 12:04:02 +02:00
Yann E. MORIN
e837837791 arch: force syntax colouring to kconfig in Config.in.*
It is too sad when an editor picks up the wrong syntax...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-05-20 22:34:16 +02:00
Ricardo Martincoski
7e26b8886b arch/Config.in*: fix attributes order
... to follow the convention: type, default, depends on, select, help.

Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-01 07:59:45 +02:00
Norbert Lange
1eecd462ae arch: add Atom CPUs as Silvermont Architecture target
The old Atom target is not really fitting for recent Atom CPUs based
on Silvermont, Airmont or Goldmont. Those have more in common with
older Desktop CPUs than old Atoms.

Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2018-01-01 13:05:16 +01:00
Thomas Petazzoni
d04ea6e4e8 arch: add BR2_READELF_ARCH_NAME hidden config option
This config option corresponds to the string returned by readelf for
the "Machine" field of the ELF header. It will be used to check if the
architecture of binaries built by Buildroot match the target
architecture.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-20 22:22:17 +01:00
Thomas Petazzoni
633f20002e i386: properly define BR2_ARCH for all x86 subarchitectures
We were not defining BR2_ARCH for two of the x86 subarchitecture,
which means the architecture part of the GNU_TARGET_NAME tuple was
empty, leading to weird build failures.

This commit fixes that by defining the appropriate values.

Fixes bug #8861.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 23:05:28 +02:00
Thomas Petazzoni
6cb4814c87 arch/x86: remove support for i386
The Linux kernel doesn't even support i386 anymore, there is no NPTL
support for i386 and uClibc-ng only supports NPTL on x86, so there is
essentially no usable thread implementation. Most likely glibc and
musl also don't support i386 either. So it's time to remove the
support for this architecture variant.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-18 23:38:34 +02:00
Thomas Petazzoni
4a3f597a0e arch: remove BR2_ARCH_HAS_ATOMICS option
Now that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can
remove it from arch/Config.in*, as well as from the documentation.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2016-02-06 11:16:00 +01:00
Peter Korsgaard
8da1239a12 arch/Config.in.x86: drop trailing dot (.) from x1000 URL
And add an empty line below for clarity.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-20 11:32:03 +02:00
Ray Kinsella
968f5d5e59 arch/x86: add support for Intel X1000
The Intel X1000 is the Pentium class microprocessor that ships with
Galileo Gen 1/2. This patch adds changes to arch and toolchain-wrapper
to omit the lock prefix for the X1000.

[Thomas: tweak commit log and Config.in help text.]

Signed-off-by: Ray Kinsella <ray.kinsella@intel.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-20 10:04:52 +02:00
Steven Noonan
f92e6219cf arch: add core-avx2
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-09 23:34:14 +02:00
Steven Noonan
c060425f67 arch: add corei7-avx
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-09 23:34:08 +02:00
Gustavo Zacarias
50451998f0 arch: add support for AMD steamroller
Add support for AMD steamroller optimizations, available in gcc 4.8+ as
bdver3.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-04 22:16:41 +01:00
Peter Korsgaard
80e4060908 arch/Config.in.x86: drop BR2_x86_generic
The fuzzy generic x86 variant doesn't make much sense in the context of
Buildroot, and the recent change to use -march instead of -mtune broke it.

From the GCC manual:

https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options:

-mtune=cpu-type
    Tune to cpu-type everything applicable about the generated code,
    except for the ABI and the set of available instructions. While
    picking a specific cpu-type schedules things appropriately for that
    particular chip, the compiler does not generate any code that cannot
    run on the default machine type unless you use a -march=cpu-type
    option. For example, if GCC is configured for i686-pc-linux-gnu then
    -mtune=pentium4 generates code that is tuned for Pentium 4 but still
    runs on i686 machines.

    The choices for cpu-type are the same as for -march. In addition,
    -mtune supports 2 extra choices for cpu-type:

    ‘generic’
        Produce code optimized for the most common IA32/AMD64/EM64T
        processors. If you know the CPU on which your code will run,
        then you should use the corresponding -mtune or -march option
        instead of -mtune=generic. But, if you do not know exactly what
        CPU users of your application will have, then you should use
        this option.

        As new processors are deployed in the marketplace, the behavior
        of this option will change. Therefore, if you upgrade to a newer
        version of GCC, code generation controlled by this option will
        change to reflect the processors that are most common at the
        time that version of GCC is released.

        There is no -march=generic option because -march indicates the
        instruction set the compiler can use, and there is no generic
        instruction set applicable to all processors. In contrast,
        -mtune indicates the processor (or, in this case, collection of
        processors) for which the code is optimized.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-07 19:51:06 +01:00
Thomas Petazzoni
6bec1d5191 arch/x86: get rid of BR2_GCC_TARGET_TUNE
According to the gcc documentation, -march implies -mtune on x86, so
defining both BR2_GCC_TARGET_ARCH and BR2_GCC_TARGET_TUNE is
redundant. Therefore, this commit removes the definition of
BR2_GCC_TARGET_TUNE on x86.

However, while doing so, it adds one new case for BR2_GCC_TARGET_ARCH:
using -march=generic when BR2_x86_generic is selected.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-07 00:09:21 +01:00
Yann E. MORIN
4f07578a86 arch/x86: all x86 but i386 has atomics operations
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18 11:03:16 +02:00
Bernd Kuhls
affb6a3853 arch: add support for "corei7" Intel CPU optimisations
gcc support was added in version 4.6:
http://gcc.gnu.org/gcc-4.6/changes.html

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-03 03:39:29 +02:00
Adrien Béraud
485f07dd4c arch: use BR2_X86_CPU_HAS_SSE4, SSE42 with jaguar
This follow-up commit adds support for SSE 4 and SSE 4.2 to
the jaguar architecture.

Signed-off-by: Adrien Béraud <adrien.beraud@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-20 22:21:11 +01:00
Adrien Béraud
a20cb38659 arch: add support for "jaguar" AMD CPU optimisations
AMD Jaguar ( https://en.wikipedia.org/wiki/Jaguar_%28microarchitecture%29 ) is
suddenly a popular architecture since it is used in the PS4 and the XBox One.
Many embedded systems are also likely to use it in the next years.

This patch adds support for GCC architecture-specific optimisations and
tuning for these CPUs.
These optimizations are available with GCC 4.8+.

Signed-off-by: Adrien Beraud <adrien.beraud@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-15 23:19:46 +01:00
Bernd Kuhls
0e8e3c2879 ffmpeg: Add sse4 related options BR2_X86_CPU_HAS_SSE4 / BR2_X86_CPU_HAS_SSE4
Signed-off-by: Bernd Kuhls <berndkuhls@hotmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-13 22:28:42 +01:00
Richard Braun
2a27ad3d79 arch: fix BR2_ARCH for generic target variant
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-12-20 15:15:24 +01:00
Thomas Petazzoni
171075ed4f arch: Config.in string configuration options must be quoted
Suggested by Yann E. Morin.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 16:39:51 +01:00
Thomas Petazzoni
44c04a2b4a arch: improve definition of gcc mtune, mcpu, etc.
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.

Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 16:12:46 +01:00
Thomas Petazzoni
79ee3c1f84 Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:

 * An initial Config.in that lists the top-level architecture, and
   sources the arch-specific Config.in.<arch> files, as well as
   Config.in.common (see below)

 * One Config.in.<arch> per architecture, listing the CPU families,
   ABI choices, etc.

 * One Config.in.common that defines the gcc mtune, march, mcpu values
   and other hidden options.

[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-04 12:51:38 +01:00