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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
