<div dir="ltr">On 5 April 2013 15:22, Matt Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div class="im">
    <div>On 04/04/2013 01:04 PM, Nick Lewycky
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">No. The test for
        DT->isReachableFromEntry(I->getBB()) is to ensure that the
        code that follows it is safe. Just because you don't have a DT
        available doesn't mean that the code in the if-body is safe.<br>
      </div>
      <br>
    </blockquote></div>
    I don't understand. My interpretation of Bill's comment is that this
    should work correctly (a conservative answer for the DT check would
    be that a block is reachable from isReachableFromEntry).<br>
  </div>

</blockquote></div><br></div><div class="gmail_extra" style>I think the conservative answer goes the other way, that the block can not be assumed to be reachable. Here's what's going on:</div><div class="gmail_extra" style>

<br></div><div class="gmail_extra" style>This function is not valid IR:</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>  define i32 @test() {</div><div class="gmail_extra" style>  entry:</div>

<div class="gmail_extra" style>    %a = add i32 %a, 1</div><div class="gmail_extra" style>    ret i32 %a</div><div class="gmail_extra" style>  }</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>

but this function is:</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>  define i32 @test() {</div><div class="gmail_extra" style>  entry:</div><div class="gmail_extra" style>    ret i32 0</div>

<div class="gmail_extra" style>  unreachable_block:</div><div class="gmail_extra" style>    %a = add i32 %a, 1</div><div class="gmail_extra" style>    ret i32 %a</div><div class="gmail_extra" style>  }</div><div class="gmail_extra" style>

<br></div><div class="gmail_extra" style>Memdep wants to start at the bottom of a use-def chain and work its way upwards. The problem is that one of the values feeding it may actually come from dead code (through a PHI node). If you reach dead code, then you can encounter IR like the above and visit %a and visit %a's operands which include %a itself which leads to an infinite loop.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>It's not the common case, but it happens. It happens rarely enough that this bug was in memdep for a long time before Bill fixed it. There are two ways that LLVM deals with this: either ask the DominatorTree whether the block is reachable from the entry block (and therefore traversing from definition to operands will never cause an infinite loop) or keeping track of visited instructions in a SmallSet.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>So if you don't know whether a block is reachable from entry, you have to assume it isn't safe to traverse from definition to operands.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>You could also try implementing an amalgam and having a SmallSet that you never use unless DT is null.</div><div class="gmail_extra" style><br></div>

<div class="gmail_extra" style>Nick</div><div class="gmail_extra" style><br></div></div>