The best benchmark is one that measures the kinds of things your code is going to do. This generally means that the best benchmark is going to be YOUR OWN CODE, from previous projects/products.
In the embedded C world, processor selection is generally controlled by hardware issues: power, size, features. Once you've selected a processor, there usually won't be that many choices of compiler, and compilers for the embedded world are generally going to be about uniformly good at generating tight code.
Also, it is generally a LOT easier to generate optimal code for modern non-x86 processors than it is for the latest generation of 8088 hardware emulation engines. (Modern x86 processors are all RISC machines emulating the x86 instruction set in microcode.) The exception to this is digital signal processors, of course: getting maximum bang for the buck out of the quirkier DSP speedups usually requires a human expert assembly language programmer, who knows how and when to use the (typically) 1-instruction 2x2 butterfly operation, the bit-reversed addressing mode, and the fast multiply-accumulate instructions, plus knowing how to exploit parallelism. Modern compilers can't really be expected to recognize radix-2 and radix-4 FFT source code.