[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]

Fri Dec 11 16:56:03 PST 2015

On Fri, Dec 11, 2015 at 4:03 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- 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.
>

The more I think about this, the more I'm inclined to move in this
direction. And I know this will make at least Philip happy. :)
One thing that may be useful to do beforehand though is to come up with a
good understanding of the current limitations from the infrastructure
w.r.t. getting around post-dominance analysis (in solving this problem).

While we're at it, let me rephrase my earlier post-dominance argument
"question" to the following:
Is this instruction dominated by an invariant_start such that either
* the invariant_start does not have a corresponding invariant_end or
* the corresponding invariant_end post-dominates the instruction?

I just realized that I mis-stated it earlier. Sorry about that.

>  -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151211/41c8e7c9/attachment.html>