<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Daniel Berlin" <dberlin@dberlin.org><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"Chandler Carruth" <chandlerc@gmail.com>, reviews+D15124+public+ddba332c127856cb@reviews.llvm.org, "Larisse Voufo" <lvoufo@gmail.com>, "llvm-commits" <llvm-commits@lists.llvm.org><br><b>Sent: </b>Wednesday, January 13, 2016 9:21:22 AM<br><b>Subject: </b>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]<br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">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><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>
</blockquote><br>Based on the way we're currently planning to generate these intrinsics in Clang, we probably need to worry only about the single-dominating-invariant_start case. That having been said, all alternatives, which involve doing repetitive "local" CFG walks, could well turn out to be more expensive than simply solving the problem (in full) up front (by which I really mean, in practice, upon first encountering one of the intrinsics). I don't have a particularly-good feel for how the relative expenses would turn out. I'm certainly okay with doing the easier thing first in this case, so long as it is sufficiently robust not to seem flaky.<br><br> -Hal<br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>