No they don't. Code size is rarely a problem (embedded probably cares..). Optimizations will in most cases lead to larger code, loop unrolling, inline expansion etc. In c the compiler cant't, in most cases do anything about memory usage. (Probably could pack structs.. , but that is not something the compiler would do I think, you would break ABI with non optimized code). In managed languages, memory usages is probably more depended on the runtime system GC, then compilers.
GCC has a flag for code size optimization -Os https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
"With -O, the compiler tries to reduce code size and execution time"
So actually yes, The compiler optimizes for both size AND speed. Sometimes you can optimize for maximum speed (-O3), and sometimes optimize for minimum code size (-Os). You can even optimize for best debugging or best compilation times, and forget about size/speed.
As for memory usage -
1. First of all - code uses up memory. smaller programs = less memory used for holding the exectuable code.
2. Consider the various ways you could compile a switch(-case) statement. You could build it as a set of conditional branches one after the other, you could compile it into a binary tree search (or a hash dictionary lookup), and you could jump to an address found in a lookup array table.
This former method is also called a "branch table". https://en.wikipedia.org/wiki/Branch_table
A branch table would be the fastest method for implementing a switch with a few sequential values (0,1,2,3,4,5) But would be a really bad idea for sparse values (0,200,5000,10000,200000).
Choosing not to use a branch table for sparse values is an optimization for Memory usage. And compilers make this decision all the time.
That depends. In game programming, if I had a choice between a render that will crash once every 10 hours and produce 60 fps (in some model envrionment) vs a render that never crashes but produces 45 fps, I would choose the first one.
Hell, I'd take a 1% chance of blowup for a 10% speedup any day.
Are you serious? Would you base your research career on software that you don't trust? I wouldn't.
Please, notice that 1% chance of full blowup means a not-null probability of nice-looking-but-actually-false results from time to time, and that's a risk no researcher is allowed to accept.
I guess you haven't seen the quality of academic code recently. The choices are basing your credibility on slow badly written code or fast badly written code.
I do however agree with underlying premise of this post: Code that works 100% of the time is better than higher performant code that explodes in your face every once in a while.