[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