Except the 64 --> 32 linker cannot use link-time code generation, which is a prerequisite of PGO.

VS2010 ships with the CRT source but not the build system.

I haven't looked at this, but the build system is apparently Very Difficult to recreate.

The 64-bit ARM architecture is ARMv8, which does not exist in any chip at the moment that I'm aware of.

http://stackoverflow.com/questions/1308500/is-iphone-os-64-bit-or-32-bit
http://en.wikipedia.org/wiki/ARMv8#ARM_cores

Because MS stopped providing the build system for the CRT sources. :-/

You'd think that we'd just figure out how to rebuild it ourselves, since we have the old build system. I don't know why we didn't, but that stuff is so ugly, I really don't want to find out. :)

Apparently this works (which surprised most of us on IRC), but doesn't support PGO, unfortunately (though unsurprisingly).

Bingo. And, of course, link-time code generation is essential for PGO.

Yeah. It's complicated for us because we do binary hacks on the CRT in order to install our custom allocator, jemalloc, and because MS stopped distributing the build system for the new CRT. But we're working on exactly the suggestions in that SO post.

Thanks. :)

That's a fair point! But right now, 32-bit Windows builds are all we have. 64-bit Windows builds have been coming Real Soon Now for a while, but I wouldn't hold my breath.

We (try to) focus our efforts where our users are. The vast majority of our users are on 32-bit Windows, so improving their experience -- however we can do that -- is in general a priority above making Firefox run fast on bleeding-edge hardware. (That's not to say that we won't optimize for new hardware now, under the assumption it will become mainstream in the future.)

Yes, we did that (omnijar). But in addition, we merged a number of previously-separate libraries into one giant library, libxul.

I have to admit, it's pretty frustrating to be on a discussion board with someone who insists that I don't understand the project I've worked on for the past few years...

Someone tried this (where test.obj is compiled with 32-bit cl.exe, since there's no 64 --> 32 cl.exe). Here's what we got:

$ link -MACHINE:X86 -LTCG -OUT:test.exe test.obj
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

fatal error C1905: Front end and back end not compatible (must target same proce
ssor).
LINK : fatal error LNK1257: code generation failed

We binary patch the CRT in order to insert our own memory allocator. This complicates things greatly.

But if you have a clue that we don't, we gladly accept patches.

According to http://msdn.microsoft.com/en-us/library/x4d2c09s(v=VS.100).aspx , there's no x64 --> x86 cross-compiler.

I have no idea what happens if I pass /MACHINE:X86, but I imagine it just invokes the 32-bit binary. If you can show that's not true, I know a large number of people who would give you a hug.

Are you sure it's not invoking a 32-bit linker? Can you show me some output which convinces me that you're right?

Because the 64-bit toolchain does not support producing 32-bit binaries. It is not a cross-compiler.

I am a Mozilla guy.

There's an official 64-bit version for Linux. We've been shipping that since before I can remember. There are also nightly builds for 64-bit Windows, but we're not shipping these even as Aurora at the moment.

64-bit Linux isn't listed on most of our download pages. I'd argue it should be there, but I'm not in charge. :)

Anyway, here are links to get all the builds we produce:

Nightly builds: http://nightly.mozilla.org/ (has win-64 builds)
Aurora builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
Beta builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/9.0b6-candidates/build1/ (I don't know the directory for the latest beta build, unfortunately, so you'll have to update this URL each time you go looking.)
Release builds: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/