You&#x27;re right; to be clear, what I was talking about above was whether the passes are decoupled at an abstract level, not so much whether the implementation uses multiple phases.<p>You can take LLVM &quot;bitcode&quot; as the <i>product</i> of clang, move it to another system with a different arch, and finish compiling the IR to a native binary on that system. This implies that the first step and second step don&#x27;t share any state other than the IR itself—meaning that flags passed directly to clang in the first phase can&#x27;t <i>affect</i> codegen, other than by influencing the generated IR; and that codegen has to treat the IR (and the environment) as its sole inputs.<p>Whereas with GCC, as far as I know, the RTL IR isn&#x27;t arch-neutral, and the GENERIC&#x2F;GIMPLE IRs aren&#x27;t fully &quot;baked&quot; yet (i.e. they&#x27;re compiler-&gt;compiler step IRs, not post-compilation pre-codegen IRs.) So there&#x27;s no conceptual guarantee (even if there&#x27;s an implementation-level one) that the compiler won&#x27;t use compile-phase state to inform codegen.<p>In other words: it&#x27;s guaranteed that you&#x27;d be able to implement the switches I&#x27;m talking about in clang+LLVM. You <i>might</i> (but won&#x27;t necessarily) have to do some work to get GCC into the right shape to implement them.