<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 14, 2017 at 4:47 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <p><br>
    </p>
    <div class="gmail-m_8665129088256811335moz-cite-prefix">On 01/14/2017 05:21 PM, Daniel Berlin
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div><br>
        </div>
        <div>In any case, if you want to play with it, it's here:</div>
        <div><a href="https://github.com/dberlin/llvm-gvn-rewrite/tree/newgvn-predicateinfo" target="_blank">https://github.com/dberlin/<wbr>llvm-gvn-rewrite/tree/newgvn-<wbr>predicateinfo</a><br>
        </div>
        <div><br>
        </div>
        <div>-print-predicateinfo -analyze will give you info.</div>
        <div><br>
        </div>
        <div>-newgvn will process simple equality and inequality right
          now using that info[1]</div>
        <div><br>
        </div>
        <div>This  is pretty much as cheap as you can make it.<br>
        </div>
        <div>We compute it in O(number of uses of comparison operations
          that are used in terminators) worst case time.  </div>
        <div>So it's not even O(number of instructions) unless your
          program is only comparisons and branches :P<br>
        </div>
        <div><br>
        </div>
        <div>This includes pruning - it will not insert predicate info
          copies except where they are actually used on a branch.</div>
        <div><br>
        </div>
        <div>(the same O(uses) algorithm works for general SSA renaming
          as well)</div>
        <div><br>
        </div>
        <div>Adding assume support would just require coming up with a
          copy operation, and doing local numbering in the assume blocks
          only (so we get def vs use order right in that block).</div>
      </div>
    </blockquote>
    <br></span>
    Looks good, thanks! The code you have in
    
    PredicateInfo::<wbr>buildPredicateInfo looks essentially like the code I
    have in AssumptionCache::<wbr>updateAffectedValues; we just need to
    update the PredicateInfo version to catch a few more cases that the
    assumptions need.<br></div></blockquote><div><br></div><div>I'm working on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    I don't understand what you mean by "in the assume blocks only." I'd
    think we'd need to treat these just like dominating
    conditional-branch conditions, so we'd need to rename all uses
    dominated by the assumption in all blocks.<br></div></blockquote><div><br></div><div>Yes, i meant The local ordering only has to be done in the assume block only, because global ordering is taken care of by dominator tree.</div><div>The way it works is by sorting in DFS order (to avoid walking the entire dominator tree just for ordering effect).</div><div>Globally, we have DFS of dominator tree to order things.</div><div>Inside the same block, you need a local DFS order (order of appearance)</div><div>The only blocks where you need such an ordering is blocks with assumes, because we don't know where in the block the assume is.</div><div>For conditionals, the value gets generated on the true/false edge, so it always comes first in the block, and we don't need any real single-block ordering for it.</div><div><br></div><div>WIthout a local ordering for assume, we will try to rename<br></div><div><br></div><div>bb1:<br><br></div><div>foo = 5</div><div>use foo</div><div>result = icmp eq foo, bar</div><div>assume(result)</div><div><br></div><div>into </div><div><br></div><div>foo = 5</div><div>use foonew</div><div>result = icmp eq foo, bar</div><div>assume(result)</div><div>foonew = predicateinfo(foo)</div><div><br></div><div>because we won't realize the def comes after the use.</div><div><br></div><div><br></div><div><br></div><div>Though now that i re-read the lang-ref, it says:</div><div>"<span style="color:rgb(0,0,0);font-family:"lucida grande","lucida sans unicode",geneva,verdana,sans-serif;font-size:14px">The intrinsic allows the optimizer to assume that the provided condition is always true whenever the control flow reaches the intrinsic call."</span></div><div><span style="color:rgb(0,0,0);font-family:"lucida grande","lucida sans unicode",geneva,verdana,sans-serif;font-size:14px"><br></span></div>Does this mean i can make go upwards  as long as the assume post-dominates the  use?</div><div class="gmail_quote"><br></div><div class="gmail_quote">If so, the above would be valid as long as i change it to:<br><br></div><div class="gmail_quote"><div>foo = 5</div><div>foonew = predicateinfo(foo)</div><div>use foonew</div><div>result = icmp eq foo, bar</div><div>assume(result)</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">which we could do easily.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div></div>