[PATCH] D15124: Use @llvm.invariant.start/end intrinsics to extend the meaning of basic AA's pointsToConstantMemory(), for GVN-based load elimination purposes [Local objects only]

[Hal Finkel via llvm-commits]

----- Original Message ----- 

> From: "Larisse Voufo via llvm-commits" <llvm-commits at lists.llvm.org>
> To: "Diego Novillo" <dnovillo at google.com>
> Cc: reviews+D15124+public+ddba332c127856cb at reviews.llvm.org,
> "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Tuesday, December 8, 2015 12:34:11 PM
> Subject: Re: [PATCH] D15124: Use @llvm.invariant.start/end intrinsics
> to extend the meaning of basic AA's pointsToConstantMemory(), for
> GVN-based load elimination purposes [Local objects only]

> On Tue, Dec 8, 2015 at 8:07 AM, Diego Novillo < dnovillo at google.com >
> wrote:

> > On Mon, Dec 7, 2015 at 10:18 PM, Reid Kleckner < rnk at google.com >
> > wrote:
> 

> > > rnk added a subscriber: rnk.
> > 
> 
> > > rnk added a comment.
> > 
> 

> > > I read through this, and tried to check my understanding of it
> > > with
> > > Larisse. Here's how I see things working:
> > 
> 

> > > - GVN processes instructions in reverse post order. This means
> > > dominating blocks come first, i.e. defs before uses.
> > 
> 
> > > - GVN's processInstruction calls
> > > llvm::processInvariantIntrinsic()
> > > on
> > > invariant intrinsics
> > 
> 
> > > - This updates InvariantMap to hold values passed to
> > > invariant.start.
> > > A call to invariant.end will remove the pointer from the map, and
> > > a
> > > new invariant.start will overwrite it.
> > 
> 
> > > - BasicAA has been modified to return MRI_NoModRef for addresses
> > > that
> > > are present in InvariantMap, as well as other things. This is
> > > what
> > > enables GVN to do better.
> > 
> 
> > > - MemDep has been modified so that when it scans backwards across
> > > an
> > > invariant start, it won't still consider the memory to be
> > > constant
> > > and load something bad like undef.
> > 
> 

> > > Fundamentally, the approach of having a side table populated by
> > > GVN's
> > > instruction visitation order makes me nervous, but I'm not able
> > > to
> > > construct a solid counterexample as to why.
> > 
> 

> > Keeping on the side data, outside of the IR can be a source of
> > headaches, yes. However, in this case this on-the side table is
> > kept
> > for the duration of the pass that invokes the analysis. The only
> > invalidation it needs to worry about is anything done by the
> > invoking pass itself.
> 

> > So, any problems caused by wrongfully moving instructions in/out of
> > the invariant region would be localized. Perhaps this could be
> > alleviated by having invariant attributes on the instructions in
> > the
> > region and a verification step that checks them. Larisse, do you
> > think this is doable?
> 
> Adding a new attribute/annotation is definitely doable, and probably
> a more general solution (if we consider later extensions in
> -globalopt for Global Variables). I am more concerned with this
> either opening up discussions about (what seems like) yet another
> syntactic extension or duplicating compiler workload...

> I think a larger problem here may be that we actually need
> post-dominance information, as in "does this load instruction
> post-dominate an invariant_start (associated with the loaded-from
> pointer values), and if an equivalent invariant_end exists, does it
> not post-dominate but rather dominate the invariant_end?"...
> However, I also understand from Chandler that LLVM has a history of
> avoiding post-dominance info computation in part because it is just
> too expensive.

Having post-dominance information is the right solution here, and that's what you should use. Yes, we've traditionally through of it as expensive, but that seems less a function of theory than of infrastructure. Computing dominance information is also expensive, but we mitigate this by caching the analysis, and actively updating it to avoid unnecessary invalidations.

Last I spoke to Chandler about this, it seemed like the right way to go about this was to compute a post-dominance tree (which is, strictly speaking, not really a tree because it can have multiple roots), at least for those blocks reachable from the entry block, as part of the same walk that computes the dominator tree. Then we need to update it whenever we update the dominator tree. If we do that, it won't be expensive, and we can use it.

 -Hal

> After further thoughts, and more to Diego's point about annotating
> instructions, I now understand Reid's point about these changes,
> though with localized effect at the moment, being dependent on the
> order in which instructions are processed. For extensibility and
> future-proof-ness reasons, this dependence will have to be
> reinforced somehow, or at the very least very well documented.

> > Diego
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-- 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory