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

[Larisse Voufo via llvm-commits]

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.

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