[LLVMdev] Optimization hints for "constant" loads

[Andrew Trick]

> On Oct 21, 2014, at 11:46 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
> Thank you for the explanation, I think I misunderstood your solution
> initially.  Is it accurate to say: by making the definition of the
> source pointer of an !invariant load control (or data) dependent on
> some initialization event, you can effectively separate the
> initialization event (where the location is not invariant) and the
> rest of the execution (where the location is invariant).
> 
> This approach looks similar to Ruby's "freeze" method:
> http://ruby-doc.org/core-2.1.3/Object.html#method-i-freeze
> 
> What is the aliasing relationship between a non-invariant load from
> the result of a safe_cast and a load from (or store to) the argument
> we pass to it?  Is it sensible to make them MustAlias?  I'm trying to
> think if a frontend needs to be careful about using the return value
> of check_cast only for !invariant loads (or some other restriction),
> or is it legal (or desirable) to mix and match both kinds of loads
> from both kinds of pointers.

%p1 = ...
store %v0, %p1
%p2 = llvm.safe_cast %p1
store %v1, %p1
store %v2, %p2
%v3 = load %p2, !invariant

The load can be moved above both stores (%v1 and %v2). AFAIK, the invariant metadata tag essentially tells alias analysis not to even try, just assume no aliasing. So the semantics effectively guarantee that %v0==%v1==%v3==%v3. The IR is still “legal” in that it is verifiable, but it is nonsense.

Note that it is also totally valid for an alias analysis to return that they MustAlias. That would allow forwarding from store %v0 to the load. This would have to be implemented as a special case, since the invariant tag normally bypasses pointer analysis. I admit this is weird, but I’m don’t know of any problems it will cause. This can already happen with TBAA, and will be a problem with any metadata that can be abused by the frontend or language design. A difficultly with this approach is that the frontend has the burden for emitting guards anywhere the “invariant” data could be modified.

How do you imagine mixing and matching invariant and non-invariant? I showed some examples of doing that safely, but I’m not sure how it’s relevant to you.

-Andy