Some code optimizations are carried out on the intermediate code because

Compilers often run certain optimization passes on an intermediate representation (IR) of the program rather than on the final machine code, because the IR is machine-independent. An optimization written against the IR keeps working unchanged no matter which target processor the compiler is retargeted to, so the same optimizer logic can be reused across many different backends instead of being rewritten for each one.

Applying this to the question: it asks why some optimizations are carried out on intermediate code. The value that matches this principle is that doing so keeps the optimization phase independent of any specific target machine — i.e., it enhances the portability of the compiler to other target processors, since the same IR-level optimizer can be reused when the compiler's back end changes.

Checking the other statements against this principle:

• Claiming that analysis is inherently "more accurate" on intermediate code overstates precision as the reason — many analyses are equally valid whether carried out on intermediate code or machine code, so accuracy is not what motivates doing the optimization at this stage.

• Saying dataflow-analysis information "cannot otherwise be used" is false — that information can be computed and applied at other stages too; the real advantage of doing it on the IR is convenience and reusability, not necessity.

• Similarly, front-end-derived information is not unusable outside the intermediate stage — it can be carried through and attached to other representations as well.

So optimizations are carried out on intermediate code because doing so keeps the optimizer machine-independent, and therefore portable across different target processors.