xpcshell should be built with "-march=native"

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
Locked
Walter Dnes
Astronaut
Astronaut
Posts: 652
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

xpcshell should be built with "-march=native"

Unread post by Walter Dnes » 2017-01-02, 20:43

I've run into a few situations where I've had to use "--disable-precompiled-startupcache". After some dead ends, I think I've found the root cause, and a solution. The following description is linux-centric with gcc, because that's all I use, but it may also apply to other OS/compiler pllatforms.

The bug... any cross-compiling situation where the target architecture code will not execute on the build architecture cpu will cause "mach package" to fai, unless "--disable-precompiled-startupcache" is invoked.

The root cause... (in linux at least) the packaging stage "mach package" executes "xpcshell" ON THE BUILD MACHINE IN THE BUILD ENVIRONMENT to generate the precompiled startup cache. This explains everything.
  • xpcshell compiled with "-march=amdfam10" will not run if built on my desktop Intel i5
  • xpcshell compiled with "-march=bonnell" will not run in the 32-bit CentOS VM which directly uses my desktop's cpu
  • xpcshell compiled with "-march=native" will work, by definition. Mind you, it's 6 hours and 15 minutes building on my Atom Netbook, even with "makeopts=-j3"
The bugfix... since xpcshell is only executed on the build machine, and is not packaged, let alone excuted on the target machine, it should be built with CFLAGS and CXXFLAGS set to "-O2 -march=native". This will work in the build environment, by definition. When grep'ing through the source, I see a lot of locations where CFLAGS and CXXFLAGS are set/modified. Setting CFLAGS/CXXFLAGS for the xpcshell code build, and re-setting them afterwards, looks like a fix that will work on both native and cross-compile builds. IANAP (I Am Not A Programmer) but this looks correct to me.
There's a right way
There's a wrong way
And then there's my way
Top
User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35591
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:
Contact Moonchild

Re: xpcshell should be built with "-march=native"

Unread post by Moonchild » 2017-01-02, 23:19

Nice theory, but it doesn't add up.
xpcshell and other built binaries can always be executed on the build machine. The build system relies on this unless you explicitly indicate you are cross-compiling in the build configuration. The precompilation of the startup cache fails for other reasons in some environments, and it's not yet clear why.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Top
Walter Dnes
Astronaut
Astronaut
Posts: 652
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: xpcshell should be built with "-march=native"

Unread post by Walter Dnes » 2017-01-03, 01:10

Moonchild wrote:Nice theory, but it doesn't add up.
xpcshell and other built binaries can always be executed on the build machine. The build system relies on this unless you explicitly indicate you are cross-compiling in the build configuration.
Is there some additional flag/option I should be setting for cross-compiles? IANAP (I Am Not A Programmer) and there's a lot I don't know. I'd really like to be able to do a personal build for my Atom on a non-Atom machine, while still enabling precompiled startupcache.
Moonchild wrote: The precompilation of the startup cache fails for other reasons in some environments, and it's not yet clear why.
"The perfect is the enemy of the good". If we can eliminate 75% of build failures, that is a worthy goal in itself. Plus, with one less factor to worry about, it becomes easier to track down the remaining problems. And finally, there is simply no logical reason to build xpcshell non-native when it only runs on the build machine/environment AND IS NOT DISTRIBUTED AS PART OF PALE MOON.
There's a right way
There's a wrong way
And then there's my way
Top
New Tobin Paradigm

Re: xpcshell should be built with "-march=native"

Unread post by New Tobin Paradigm » 2017-01-03, 03:05

I think a good question is.. What are you directly using xpcshell for specifically.. Since it is not distributed with production binaries I am not sure why the development team should actually care.
Top
Walter Dnes
Astronaut
Astronaut
Posts: 652
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: xpcshell should be built with "-march=native"

Unread post by Walter Dnes » 2017-01-04, 20:04

Matt A Tobin wrote:I think a good question is.. What are you directly using xpcshell for specifically..
xpcshell is executed by the build process to populate the "precompiled startupcache" during the "mach package" stage. It can be omitted, but that results in no precompiled startupcache, which results in longer startup times the first time after an install or upgrade.

Question... is it possible to include a pre-built, "precompiled startupcache" with the git code. OK, maybe 2 versions (32 and 64 bit).
There's a right way
There's a wrong way
And then there's my way
Top
Locked

Return to “Browser Development”