Bug 139 - Set default gcc instruction generation to TARGET_ARCH on target
Summary: Set default gcc instruction generation to TARGET_ARCH on target
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: devtools / tool chain (show other bugs)
Version: 2.5
Hardware: All Multiple
: Low enhancement
Target Milestone: Future
Assignee: Khem Raj
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2010-07-22 07:50 UTC by Joshua Lock - Disabled
Modified: 2020-03-24 15:14 UTC (History)
9 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
MeeGo's patch to use Atom optimisations by default in GCC (2.72 KB, patch)
2010-07-22 07:50 UTC, Joshua Lock - Disabled
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Lock - Disabled 2010-07-22 07:50:22 UTC
Created attachment 21 [details]
MeeGo's patch to use Atom optimisations by default in GCC

It would be useful if the cross compiler shipped with meta-toolchain defaulted to generating instructions for the CPU type of the cross-compilation target.

Currently we export CFLAGS="-march=${BASE_PACKAGE_ARCH}" in the environment set up script for meta-toolchain but there's probably a nicer way to do this.

MeeGo patches GCC to use Atom optimizations by default (see attached patch), however this tactic wouldn't work well for the multiple architectures Poky targets.

Some preliminary investigation by Richard suggests that modifying SUBTARGET32_DEFAULT_CPU could be the right approach, but more investigation is required.
Comment 1 Nitin Kamble 2010-12-14 20:33:06 UTC
I will look into this.
Comment 2 Julie Fleischer 2011-02-14 17:37:16 UTC
Jessica may have a fix.
Comment 3 Nitin Kamble 2012-05-02 22:47:01 UTC
this may be already fixed in the current code
Comment 4 Richard Purdie 2012-05-11 10:58:57 UTC
No, its not already fixed.
Comment 5 Radu Moisan 2012-11-14 23:06:12 UTC
Any news about this?
Richard, Nitin can anyone of you guys give me an ideea of what the workload is for this feature? I'll go with 5 days for now so we can schedule it and update appropriate once I have handle on it.
Comment 6 Richard Purdie 2012-11-15 10:18:38 UTC
I think the gcc-cross-canadian problem has been solved since the environment scripts contain the relavent information and that is probably as good as we're going to get. You'll need to use those scripts since there are other key variables set there.

This bug was left open as this problem still exists for the "on target" gcc where if you just use "gcc" on the target, you will not get optimised binaries for that platform. I'm adjusting the bug to reflect this. The patch Joshua attached is still relavent for this.
Comment 7 Khem Raj 2017-09-06 13:50:16 UTC
We could configure target gcc using --with-cpu=native which should generate code for the same processor flavor that GCC itself is running on
Comment 8 Richard Purdie 2019-10-24 15:03:07 UTC
We did start to do this for some platforms:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/gcc/gcc-target.inc

EXTRA_OECONF_append_armv6 = " --with-arch=armv6${ARMFPARCHEXT}"
EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a${ARMFPARCHEXT}"
EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve${ARMFPARCHEXT}"
EXTRA_OECONF_append_arc = " --with-cpu=${TUNE_PKGARCH}"
Comment 9 Richard Purdie 2019-10-24 15:04:03 UTC
If native would work on the target, that would be a better alternative.
Comment 10 Ross Burton 2019-10-28 15:31:34 UTC
No expert on GCC building here.  Would changing that bundle of --with-arch assignments to --with-cpu=native be sufficient?
Comment 11 Khem Raj 2020-03-16 21:14:10 UTC
(In reply to comment #10)
> No expert on GCC building here.  Would changing that bundle of --with-arch
> assignments to --with-cpu=native be sufficient?

--with-arch=native could work on x86_64 only, perhaps it should be done like what we have done with ARM ones, this, however, would mean if someone was to recompile a package natively then it won't use same options as used during cross-compile but perhaps thats acceptable compromise.
Comment 12 Khem Raj 2020-03-17 07:17:52 UTC
patch to add march=native for x86_64 is on ml
Comment 13 Khem Raj 2020-03-24 15:14:08 UTC
I think we can close it now as the patch is in core