Chromium is compiled with -Darmv7=0 -Darm_neon=0, which can greatly improve performance on armv7 and neon-enabled hardware, such as most Cortex-A8/A9 CPUs. Reproducible: Always Steps to Reproduce: 1. Emerge Chromium 2. See for flags at compile time Actual Results: Chromium compiled for most generic arm, ignoring all optimizations for specific hardware Expected Results: Chromium should be compiled for certain hardware
Vladimir, do you have some patch suggestions? I don't really use ARM here - it'd be great to get some patches/testing from people who do.
if needed I can test, CC me
Created attachment 351156 [details, diff] chromium-28.0.1500.45-arm.patch (In reply to Paweł Hajdan, Jr. from comment #1) > Vladimir, do you have some patch suggestions? > > I don't really use ARM here - it'd be great to get some patches/testing from > people who do. I'd say, for "-Darmv7=0" we do the same as in dev-lang/v8. And for "-Darm_neon=0" adding a neon USE-flag plus configure switch should be enough. Attaching proposed changes (untested!).
Created attachment 351158 [details, diff] Proposed patch In fact there are more problem. I've tried to address them in this patch. Chromium will fail to compile on arm-hardfloat if you won't pass hardfloat abi param in config.
I don't think using CTARGET here is appropriate; we are not building a cross-compiler. CBUILD maps to the "host" toolchain in gyp. CHOST maps to the "target" toolchain in gyp.
Both CTARGET and CHOST are used in tc-is-softfloat function. As it's written in http://www.gentoo.org/proj/en/base/embedded/cross-development.xml, CTARGET is platform, that cross-toolchain builds for. AFAIK, chromium can't be cross-compiled with current ebuild, but still, I think it's better to make it as much cross-friendly, as possible.
The relevant description from that page is in the Meaning When Building Cross Binaries column. CTARGET: Platform running the cross binary. Which certainly fits the bill here. I retract my earlier comment.
Comment on attachment 351158 [details, diff] Proposed patch the is-flagq check for neon is incorrect. it should be USE=neon and orthogonal to any cpu check. i'm not sure why the Gentoo ebuild is disabling nacl. maybe old code ? we're building nacl in CrOS fine ... might want to also see the defines we use in CrOS ... there's some v8 stuff in there we probably want. http://git.chromium.org/gitweb/?p=chromiumos/overlays/chromiumos-overlay.git;a=blob;f=chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild;hb=HEAD#l236
(In reply to SpanKY from comment #8) > Comment on attachment 351158 [details, diff] [details, diff] > Proposed patch > > the is-flagq check for neon is incorrect. it should be USE=neon and > orthogonal to any cpu check. > > i'm not sure why the Gentoo ebuild is disabling nacl. maybe old code ? > we're building nacl in CrOS fine ... > > might want to also see the defines we use in CrOS ... there's some v8 stuff > in there we probably want. > > http://git.chromium.org/gitweb/?p=chromiumos/overlays/chromiumos-overlay.git; > a=blob;f=chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild; > hb=HEAD#l236 I've used is-flagq for neon check, because you can't specify mfpu=vfp* and USE=neon at the same time. Chromium build system, by default, will add defines for neon, add -mfpu=neon and then it'll be overriden by user's -mfpu=vfpv3-d16, for example. Gcc will fail to compile neon code with wrong -mfpu flag. If is-flagq is worse then use flag, then it's better to filter out mfpu completely and pass -Darm_fpu=${ARM_FPU} to build system.
Created attachment 351188 [details, diff] chromium-29.0.1521.3-arm.patch Another proporsal. By the way, I think CTARGET should be compared to arm[78], not only to arm7.
(In reply to Vladimir from comment #10) > Created attachment 351188 [details, diff] [details, diff] > chromium-29.0.1521.3-arm.patch > > Another proporsal. I think I can apply that patch. Any comments before I do? Mike (vapier)?
(In reply to Paweł Hajdan, Jr. from comment #11) > (In reply to Vladimir from comment #10) > > Created attachment 351188 [details, diff] [details, diff] [details, diff] > > chromium-29.0.1521.3-arm.patch > > > > Another proporsal. > > I think I can apply that patch. Any comments before I do? Mike (vapier)? yes, please apply it, since chromium-29* doesn't build on arm hardfloat anymore with the current ebuilds. compiles and works fine with attachment 351188 [details, diff]. thanks in advance!
(In reply to Mike Gilbert from comment #5) > I don't think using CTARGET here is appropriate; we are not building a > cross-compiler. > > CBUILD maps to the "host" toolchain in gyp. > CHOST maps to the "target" toolchain in gyp. I'm pretty certain Mike Gilbert is correct. The three C* variables are: CBUILD: What arch will build the binaries? CHOST: On what arch will the binaries execute? CTARGET: For what arch will the binaries produce output? Unless you're building a compiler, CTARGET doesn't have any meaning. If CHOST != CTARGET, you're building a cross-compiler. If CBUILD != CHOST, you're cross-compiling. (And, logically, if CBUILD != CHOST != CTARGET, you're cross-compiling a cross-compiler.) FWIW, I too would like to see Chromium built for ARM with -Darmv7=1 -Darm_neon=1 -Ddisable_nacl=0.
Patch applied in chromium-30.0.1588.0, thanks! Please send any further changes in a new bug.
