I had a professor once who called C "a macro assembler that comes with lots of already-defined macros and features".

this is exactly what I consider absolutely unnecessary (even harmful) - to modify the C code so that it compiles into effective (in any way) binary - unless you are the compiler maker.

Unfortunately, the compiler cannot do a lot of thinking for the programmer, especially if high-level aspects and possible side-effects of the program are concerned.

On a processor that supports a "decrement and jump if not zero"-type of instruction, a while(i--) loop will be slower than a do/while(--i), unless the compiler tries to be very, very (maybe too) clever (and, for example, realizes that the check for the exit condition can be moved to the end of the loop if i cannot be zero at the start). Also, counting down to zero in loops will usually be faster than counting up (unless your architecture has zero-overhead-looping features and the compiler actually knows how to use them).

That's why for pretty much every compiler and architecture, there's a "How to write optimal C" document to go along with it. A certain DSP architecture I used in a project came with very, very detailed instructions on the syntax to use so the compiler would actually emit MAC instructions.