[LLVMdev] A question about LICM (Loop Invariant Code Motion)

[Andrew Trick]

On Feb 8, 2011, at 7:36 AM, Reid Kleckner wrote:

> On Tue, Feb 8, 2011 at 4:55 AM, Duncan Sands <baldrick at free.fr> wrote:
>> Hi Yuelu,
>> 
>>> After tracking the LICM pass, I find that both loads are loop
>>> invariant, and canSinkOrHoist() also returns true; however the
>>> difference is at Instruction::isSafeToSpeculativelyExecute(),
>>> for load from function parameter pointer, it return false; with load
>>> from a global var pointer, it returns true. As a result no hoist
>>> happens for a load *fp:
>> 
>> the function parameter pointer might be null.
> 
> I suppose you could peel a single iteration to try to work around that.

Peeling is a good idea for small loops with invariant loads or
conditions. I'm not sure why we don't do it. But it would cause code
bloat (in the absense of profile data) and it's not a general solution.

If null checks were the only problem, then the compiler could hoist the
load under a non-null condition (e.g. select), replacing the original
with a trap under the inverse condition. But even if the entire loop
is dominated by a null check, it's still unsafe to hoist the load.

The fundamental problem is that the language needs to guarantee that
the load is safe to speculate. Modern languages do this. But I don't know
how to represent that information in LLVM IR. We would need a way
to indicate a load's control dependent conditions (null checks, type
checks, and such).

-Andy