The following list describes the various versions of cl.exe (the Visual C++ compiler):
...
x64 on x86 (x64 cross-compiler)
Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit Widows operating system.
What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows.
This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output.
They use to be doing 1, now they are doing 3. They need to do 4, but apparently cannot. My understanding of this may be wrong, or they may be wrong, I don't know.
I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use?
I am baaarely familiar with Microsoft-world development.
You can't use a 32-bit cl.exe and a 64-bit linker to produce 32-bit binaries if you're doing PGO (which is the whole point of this "using lots of memory" issue). In particular, the 64-bit linker can't produce 32-bit binaries when you're using link-time code generation, which PGO does.
I am talking about the cl.exe executable that output x86-32 code itself, not the code it produces. You can use a 32-bit cl.exe to cross compile 64-bit code, but not the other way round.