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

[Xinliang David Li via llvm-commits]

With memory ssa in place in the future and when memory SSA starts to
support more fine grained memory partition/token, it seems to me handling
invariant-start/end fits naturally in that framework -- each global that
has associated invariant region can be assigned with a distinct memory
token which are defined/killed by invariant-start/end.

David

On Wed, Jan 13, 2016 at 7:21 AM, Daniel Berlin via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> This works if there's only one start. If there are multiple starts, then
>> we need only the set to dominate, not any individual one.
>>
>> invariant_start         invariant_start
>>           |                             |
>>           |________________ |
>>                          |
>>                        load
>>                          |
>>                         ret
>>
>> At least in theory, this is fine too. The "right" way to solve this might
>> be to set it up as a lattice/dataflow problem on the CFG, and then iterate
>> until convergence (which should happen in two iterations, aside perhaps
>> from pathological cases).
>>
> Yes, you can't solve this sparsely without virtual phi nodes for the data,
> and it's not clear to me it's worth the cost of doing that.
>
> (I've seen compilers that do it for extra data they want to use during ssa
> optimizations, but ... so far i'd say not worth it)
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160113/a76282e2/attachment.html>