Outsmarting the compiler refers to any attempt to defeat the optimization heuristics (or other techniques for code improvement) of a compiler, often with the hubris that expert programmers can do better at code generation than modern optimizing compilers. (While this may be true, most expert programmers know better to outsmart the compiler except in specific circumstances; conversely most programmers who spend lots of time trying to outsmart compilers aren't experts, and often make things worse.)
Unless profiling tells you that your compiler is doing the wrong thing, and this is leading the code to not meet its performance requirements, doing so is PrematureOptimization, and as such is an AntiPattern.
OutsmartingTheCompiler is frequently bad because:
It causes precious programmer resources to be focused on details of the language implementation, and not solving the customer's problem.
It usually produces code which is less portable (or not at all). Even if no non-portable constructs are used, the result is often code which performs well on one platform and sucks on others. (If you let the optimizer do its job, it can produce good code for any platform).
It can interfere with debugging (the same is true of many compiler optimizations in general).
It can interfere with maintenance. Many JavaLanguage maintenance programmers have yanked out hair due to predecessors who declared methods (or entire classes) to be "final" just to avoid DynamicDispatch and squeeze out a few more cycles.
On the other hand, it is occasionally useful because:
Sometimes, profiling does reveal bottlenecks that the compiler won't fix.
Some compilers are flat-out not very good. (In many cases, the correct fix is to get a better compiler; but for many languages/environments a SufficientlySmartCompiler doesn't exist)
Programmers do have access to information (and can thus enable optimizations) that are difficult or impossible (equivalent to the HaltingProblem) for the compiler to infer or discover. For example, declaring pointers to be restrict-ed in AnsiCee (latest revision)--the compiler generally won't do this for you as the semantics of CeeLanguage make the requisite alias analysis impossible. Of course, the programmer had better be right!
Examples of outsmarting the compiler:
Embedding of numerous performance hint directives (inline, register, restrict in C/C++ for example) in the code. Occasional use of "inline" is generally considered acceptable, and see comment on restrict above.