What is loop-invariant code motion in an optimizing compiler, and which conditions prevent it from hoisting a field load or a computation out of a loop?

## The idea If a computation inside a loop produces the same value on every iteration, computing it once is strictly better. Loop-invariant code motion is the pass that finds those computations and moves them into a **pre-header** — a block the compiler inserts on the single path into the loop — leaving the loop body to reuse the already-computed value. What counts as invariant is defined recursively: an operation is invariant if all its operands are defined outside the loop, or are themselves invariant operations. So `base * scale` where neither is written in the loop is invariant; so, by induction, is `(base * scale) + offset`. ## Why memory makes this hard Pure arithmetic is easy. Memory is where the analysis actually lives, because a load is invariant only if nothing in the loop can write the location it reads. The compiler builds a model of memory effects and asks, for each load, whether any store in the loop — or any call it could not analyse — might target the same location. Several things force a conservative "yes": - **A visible store in the loop** to the same field or array element. Obvious, and correct to respect. - **A call that was not inlined.** An opaque call could write any reachable field, so every load of a possibly-reachable location must be repeated after it. This is one of the underrated benefits of inlining: it converts opaque calls into analysable code and unlocks LICM. - **Aliasing.** If the loop stores through reference `p` and loads through reference `q`, and the compiler cannot prove `p != q`, the load must stay. Type information helps — a store to a `long[]` cannot alias a load from an `Object[]` field — but references of the same type frequently defeat it. Array length is the happy exception: it is immutable for the life of the array, so the length load is invariant as long as the array *reference* is not reassigned in the loop. That is why `i < a.length` costs nothing per iteration in compiled code. ## What else blocks hoisting **Ordering constraints.** A `volatile` read carries acquire semantics: it must not be reordered with the accesses that follow it, and the program is entitled to see a new value on each execution of the read. The compiler therefore cannot collapse repeated volatile reads into one hoisted load. The same holds for reads inside a synchronized region relative to the monitor operations, and for the ordering-sensitive accessors in `VarHandle`. This is the concrete reason a status flag intended to stop a loop must be declared appropriately — an ordinary field read is exactly the kind of load LICM is designed to hoist. **Speculative execution of work that might not run.** Hoisting moves a computation to a point that executes even if the loop body executes zero times. For pure arithmetic, that is harmless (worst case, wasted work). For anything that can throw — a division, a null dereference, an array access — or that has a side effect, it is not: the program could observe an exception the original never reached. The compiler therefore either proves the loop runs at least once, or moves the operation under a guard, or leaves it alone. HotSpot's loop predication is precisely the guarded form: the condition is hoisted into a predicate whose failure path deoptimizes to the interpreter, so the exception, if any, still happens in the right place. **Register pressure.** Even when hoisting is legal it is not always profitable. Every hoisted value occupies a register across the whole loop; hoist too many and the allocator spills to the stack, and the spill reloads cost more than the recomputation would have. Compilers apply heuristics here, and an aggressive-looking transformation can be declined for this reason alone. ## Its relatives LICM rarely acts alone. It is usually run alongside common-subexpression elimination (which merges identical computations wherever they appear), induction-variable simplification (which rewrites `i * stride + base` into a pointer advanced by a constant each iteration — strength reduction), and the loop predication that underpins bounds-check elimination. Together they turn a source-level loop full of repeated address arithmetic and checks into a body containing only the essential loads, arithmetic, and stores. ## What to take away If you are reasoning about why a loop is slower than expected, ask what stops the compiler from hoisting: an opaque call in the body, a store that might alias, a field read that is ordering-sensitive by design. And when you are reasoning about *correctness* rather than speed, remember the flip side — hoisting a repeated read of an ordinary field is a legal, expected transformation, so any loop whose termination depends on another party changing a field must use a mechanism that carries the required ordering rather than hoping the load is repeated.