Use more explicit architecture compiler options on Linux

[aaronfranke]

This PR takes a piece out of #55778. Specifically, this PR was driven by this review comment from @akien-mga:

I tested this PR on x86_64, arm64, and rv64 hosts & targets, and compiling x86_32 on x86_64.

[akien-mga]

You seem to have missed some cross-compilation code further down that does some of this already, which should likely be removed. The hardcoded lib folder path are actually bogus on many distros, but shouldn't be needed(?).

diff --git a/platform/linuxbsd/detect.py b/platform/linuxbsd/detect.py
index 72bffceb1f..02d8d20fbf 100644
--- a/platform/linuxbsd/detect.py
+++ b/platform/linuxbsd/detect.py
@@ -469,16 +469,6 @@ def configure(env: "Environment"):
     if platform.system() == "FreeBSD":
         env.Append(LINKFLAGS=["-lkvm"])
 
-    ## Cross-compilation
-    # TODO: Support cross-compilation on architectures other than x86.
-    host_is_64_bit = sys.maxsize > 2**32
-    if host_is_64_bit and env["arch"] == "x86_32":
-        env.Append(CCFLAGS=["-m32"])
-        env.Append(LINKFLAGS=["-m32", "-L/usr/lib/i386-linux-gnu"])
-    elif not host_is_64_bit and env["arch"] == "x86_64":
-        env.Append(CCFLAGS=["-m64"])
-        env.Append(LINKFLAGS=["-m64", "-L/usr/lib/i686-linux-gnu"])
-
     # Link those statically for portability
     if env["use_static_cpp"]:
         env.Append(LINKFLAGS=["-static-libgcc", "-static-libstdc++"])

Edit: I'm moving this up in #84307 which will conflict with this PR, but it's a safe-ish fixup for 4.2. You can rebase and remove that whole block as yours supersedes it fully.

[akien-mga]

Are both -m64/-m32 and -march needed at the same time, or does the latter make the old -m64 and -m32 flags redundant?

[aaronfranke]

They are both required, yes.

If you try to use -march= on x86 without the proper bitness or specifying -m32/-m64 it will not work.

While confusing, -m32/-m64 specifically refers to x86_32 and x86_64, not 32-bit and 64-bit in general.

[Calinou]

Tested locally, it works as expected.

elfx86exts output before and after on a Linux release export template:

File format and CPU architecture: Elf, X86_64
MODE64 (call)
SSE2 (movdqu)
SSE1 (movups)
CMOV (cmovne)
MMX (movq)
BMI (tzcnt)
AES (aesenc)
PCLMUL (pclmulqdq)
NOT64BITMODE (xchg)
BMI2 (shlx)
Instruction set extensions used: AES, BMI, BMI2, CMOV, MMX, MODE64, NOT64BITMODE, PCLMUL, SSE1, SSE2
CPU Generation: Unknown

Binaries before and after this PR are byte-for-byte identical in size too, so there's no change in the CPU optimizations applied.

[akien-mga]

Use CCFLAGS for those if it's the same for C and C++.

[akien-mga]

I see #64366 (comment). This should be documented with a comment.

But this is also exactly why I haven't fully been able to approve this PR, as I'm worried about exactly these implications of forcing some defaults which may not be what users want to use. We already have similar issues with use_llvm=yes forcing CC=clang CXX=clang++ which can also be problematic, so it's not new to be clear.

But there are implications to explicitly spelling out default values like this. That being said I also see value in being explicit about what we expect to be used by default.

I started some WIP in the same area but didn't have time to continue. The scope is bigger than just Linux, and it includes an option to skip setting these defaults:

akien-mga@1e4aef2 (branch https://github.com/akien-mga/godot/tree/scons-explicit-march-mtune)

[aaronfranke]

In your branch, why is it needed to have a env["default_arch_flags"] bool to disable the default arch flags? If users desire specific arch flags, they should be able to override it as @MonterraByte mentioned.

[MonterraByte]

Yeah. In this case, it's fine to always set -march, because if the user sets -march a second time, it will override the first value. This is true for both GCC and Clang. (Not for MSVC, but that's not relevant here.)

You can verify this with gcc -march=x86-64 -march=x86-64-v3 -dM -E - < /dev/null | grep AVX.