[LLVMdev] TBAA vs !invariant.load metadata semantics

Philip Reames listmail at philipreames.com
Mon Dec 1 15:44:02 PST 2014


(Spawning a separate subthread off the 'Optimization hints for 
"constant" loads' discussion for a related question. )

Looking at TBAA again, I was reminded that TBAA also contains a third 
field which indicates that "meaning pointsToConstantMemory should return 
true; see other useful AliasAnalysis methods 
<http://llvm.org/docs/AliasAnalysis.html#OtherItfs>".  Looking at this a 
bit, it really seems like this flag has the exact same meaning as 
!invariant.load.

pointsToConstantMemory returns a value for a Location.  Since it is 
entirely legal to have two Locations which describe the same physical 
memory, it seems like you'd be back to the same semantics as 
!invariant.load.

The only uncertainty here is that a Location is clearly (??) 
position/Instruction specific.  Does that also imply that the Location 
is control dependent?  What is the semantics of the following code?
if (is_known_invariant) {
   load %p, !tbaa is_constant=true
}

Is the optimizer allowed to lift the load above the conditional? 
(Assuming it can prove the location is known dereferenceable.)  The 
semantics for !invariant.load clearly allow this, but do the semantics 
for TBAA's constant flag?

I think the answer to these questions is that the load is *not* control 
dependent on the conditional (assuming it's otherwise known 
dereferenceable).  Given this, why do we have both?  Should we 
canonicalize one into the other?

Looking at the current implementations, it appears that TBAA's constant 
flag is more broadly implemented.  On first glance, I'm really tempted 
to just deprecate !invariant.load in place of TBAA's constant flag.  
Thoughts?

Philip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141201/976b2945/attachment.html>


More information about the llvm-dev mailing list