<div dir="ltr">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.<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 7:21 AM, Daniel Berlin via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">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.<br><br>invariant_start         invariant_start<br>          |                             |<br>          |________________ |<br>                         |<br>                       load<br>                         |<br>                        ret<br><br>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). </div></div></blockquote></span><div>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.</div><div><br></div><div>(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)</div></div></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>