To be more specific about what Martin says below under "...does not feel like a very useful or predictable optimisation": In Java for example, method call sites provide zero ordering semantics with the surrounding code. A compiler *may* inline any method (even truly polymorphic ones) at any call site. And if a compiler does happen to inline a method it may reorder the operations in that methods with operations that occur in the caller both before and after the call site. And along with that reordering, operations in the caller that occur before and after the call site may be reordered against each other as well.
So:
doA
f()
doB
does not imply anything about the execution order of otherwise unrelated operations doA and doB.
e.g. if f() was basically "doC", the above may be legitimately reordered to be:
doC
doB
doA
On the other hand, *if* a compiler fails to inline a method, and *if* it has also no other useful knowledge that restricts what that method might end up doing (the "opaque" quality in the subject), then since the method *may* contain operations that force ordering, the compiler will generally lose the ability to reorder caller operations across the method call site. But (in Java at least) there is no way to semantically force that "loss of ability" to happen, so it cannot be relied on...