CoreMark run rules allow for any compiler optimizations. Unlike Dhrystone, CoreMark relies on a design that forces any computation to happen at compile time by tracing any computation chain from a value that is not available at compile time and ends with an output.
While compilers can find more efficient ways of implementing those computations, the computations cannot be done at compile time, and thus actual operation cannot be “optimized away”. Dhrystone for example was split to multiple files since the advent of the technique called inlining allowed compilers to avoid performing the very tasks the benchmark was trying to analyze. Since compilers can now analyze the program even when it is split to multiple files, this cure did not work…
In fact, many modern architectures rely on the compiler to create code that can make efficient use of hardware resources, and restricting the compiler from optimizing is not a reasonable restriction. CoreMark does not attempt to force a specific number of branches or loads, rather only that all computations are performed at run time. Complex architectures are going to find different ways of doing those computations (e.g. SIMD, predicated execution and more), while simple architectures are going to perform the operations head on. As long as the operation is performed, the benchmark is useful to analyze the performance potential of the core.