<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
(Spawning a separate subthread off the 'Optimization hints for
"constant" loads' discussion for a related question. )<br>
<br>
Looking at TBAA again, I was reminded that TBAA also contains a
third field which indicates that "meaning
<tt class="docutils literal"><span class="pre">pointsToConstantMemory</span></tt>
should return true; see <a class="reference external"
href="http://llvm.org/docs/AliasAnalysis.html#OtherItfs">other
useful
AliasAnalysis methods</a>". Looking at this a bit, it really
seems like this flag has the exact same meaning as !invariant.load.
<br>
<br>
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. <br>
<br>
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?<br>
if (is_known_invariant) {<br>
load %p, !tbaa is_constant=true<br>
}<br>
<br>
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? <br>
<br>
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?<br>
<br>
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?<br>
<br>
Philip<br>
<br>
<br>
<br>
</body>
</html>