<div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Jul 9, 2017 10:24 AM, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br type="attribution"><blockquote class="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"><div class="quoted-text"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></span>
Matt Simpson and I briefly discussed this transformation.  One of his suggestions was to add a pass in the pipeline where the dominator tree was available (note my patch used a poor man's version of domination) and to add range meta-data to values (or replace values if we know the exact value) based on dominating conditions.  </blockquote><div><br></div></div><div>This is a pretty trivial variant of what the predicateinfo utility  does :)</div><div> </div><div>(it just happens to process branches, assumes, etc. But you could trivially modify it to change the name anywhere the range is different, to ensure the invariant that anything with the same ssa name has the same range)</div><div class="quoted-text"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I thought it was pretty interesting idea, but I'm not very familiar with how range metadata is generated and used.<div class="m_4584165912273689449HOEnZb"><div class="m_4584165912273689449h5"><span style="color:rgb(34,34,34)"></span></div></div></blockquote></div><div>GCC pretty much does what i said above:</div><div>It generates assert_expr's, which rename values, where the ranges change (this is equivalent to what predicateinfo does), then solves a lattice over the resulting IR.</div><div> </div></div></div></div></blockquote></div></div><div dir="auto">We have a related bug open, you opened, it seems :)</div><div dir="auto"><a href="https://bugs.llvm.org/show_bug.cgi?id=31895">https://bugs.llvm.org/show_bug.cgi?id=31895</a><br></div><div dir="auto"><br></div><div dir="auto">From what I can tell the difference is that gcc solves the problem eagerly (and not lazily). Actually, they catch this case as part of VRP, which is run not very early in the pipeline but still the cfg is in a shape decent enough to get this case right (maybe we could consider reordering passes, instead).</div><div class="gmail_extra" dir="auto"></div></div>