<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 17, 2014 at 4:39 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":599" class="a3s" style="overflow:hidden">Some points for discussion [by Philip, edited slightly by me]:<br>
<br>
 1. The current patches remove llvm.invariant(undef) as dead. Would it be better to transform this into 'unreachable' as is done for llvm.invariant(false).<br></div></blockquote><div><br></div><div>I strongly thing "yes". With undef, we are granted permission to chose the most useful value for optimization which is 'false' here.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":599" class="a3s" style="overflow:hidden">
<br>
 2. Would adding a canonicalization of if(c) { unreachable } to llvm.invariant(c) would be worthwhile?<br></div></blockquote><div><br></div><div>There was a long and painful attempt to implement invariants based on the branch-to-unreachable pattern. It didn't work. I don't expect these patterns to show up often organically and to go away too soon in the optimizer to be useful. The whole point of 'llvm.invariant' instead of the if construct is to distinguish between the case the optimizer should try to remove (a branch to unreachable) and the case the optimizer should try to preserve because of some specific utility. We shouldn't lose this important distinction.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":599" class="a3s" style="overflow:hidden">
<br>
Finally, I'd like to mention that alternate schemes are certainly possible:<br>
<br>
 1. We could 'hide' all invariants inside dominating blocks guarded by never-true conditional branches (this has the benefit of being able to express invariants using expressions that normally might have side effects, and could simplify the process of finding applicable invariants) [a suggestion by Richard and Nick].<br>
</div></blockquote><div><br></div><div>I'm really concerned about the increased complexity and cost of invariants in this pattern. I would like to go with the simpler and less intrusive design until we have some compelling evidence that we need to support the more general form.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":599" class="a3s" style="overflow:hidden">
<br>
 2. We might want to have passes precompute the Value->(set of Invariants) map, and update it as necessary instead of doing transitive-user searches [a suggestion by Chandler].<br></div></blockquote><div><br></div><div>
I think this is mostly just a small API tweak to make the code more maintainable. I'm specifically *not* imagining this as a formal analysis pass or anything of the sort.</div></div></div></div>