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

[Diego Novillo via llvm-commits]

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?


Diego
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151208/adacacb3/attachment.html>