<div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <span dir="ltr"><<a href="mailto:mcurtis@codeaurora.org" target="_blank" class="cremed">mcurtis@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hello all,<br>
    <br>
    For the hexagon target, we have a couple of tests that are failing
    due to variations in the order of checked text. In these cases the
    ordering is not directly relevant to the functionality being tested.<br>
    <br>
    For example:<br>
    <blockquote><tt>; CHECK: memw(##a)</tt><br>
      <tt>; CHECK: memw(##b)</tt><br>
      <br>
      <tt>%0 = load i32* @a, align 4</tt><br>
      <tt>%1 = load i32* @b, align 4</tt><br>
    </blockquote>
    requires that the compiler emit the memory operations for 'a' and
    'b' in that order, even though the intent of the test might simply
    be to ensure that each 'load' results in a memory read.<br>
    <br>
    I'd like to teach FileCheck to allow tests to be more tolerant of
    these incidental variations.<br></div></blockquote><div><br></div><div>So, I'm not a huge fan of this, but for a strange reason.</div><div><br></div><div>Fundamentally, I agree with you that these ordering dependencies are unfortunate in tests. However, I would make a few observations:</div>
<div><br></div><div>1) The order of instructions, unlike some things such as register allocation's selection of registers, should ideally not vary much. Currently it does more that we would like due to the inability to unit test single pieces of the backend, but I don't think we should make FileCheck better to cope with that, I think we should fix the underlying problem.</div>
<div><br></div><div>2) It is usually fairly obvious when two such checks don't actually have an ordering constraint that is important, and where it isn't, a comment makes the intent clear.</div><div><br></div><div>
3) By checking the ordering, we gain at least some early detection of non-determinism in the code generator. I definitely caught several bugs in the block placement pass while I was working on it due to this very "feature" of the test suite.</div>
<div><br></div><div><br></div><div>Given these points, the value tradeoff here of making FileCheck *significantly* more complicated (and the tests significantly more complex as well) versus the time savings updating test cases when the ordering changes...</div>
<div><br></div><div>But maybe others who have spent more time hammering against these problems in the backend have a different sense of the magnitude of the problem?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
    <br>
    The attached patch implements one possible solution. It introduces a
    position stack and a couple of directives:<br>
    <ul>
      <li>'CHECK-PUSH:' pushes the current match position onto the
        stack.</li>
      <li>'CHECK-POP:' pops the top value off of the stack and uses it
        to set the current match position.</li>
    </ul>
    The above test can now be re-written as:<br>
    <blockquote><tt>; CHECK-PUSH:</tt><br>
      <tt>; CHECK: memw(##a)</tt><br>
      <tt>; CHECK-POP:</tt><br>
      <tt>; CHECK: memw(##b)</tt><br>
      <br>
      <tt>%0 = load i32* @a, align 4</tt><br>
      <tt>%1 = load i32* @b, align 4</tt><br>
    </blockquote>
    which handles either ordering of memory reads for 'a' and 'b'.<br>
    <br>
    Thoughts?<br>
    <br>
    Thanks,<br>
    Matthew Curtis<span class="HOEnZb"><font color="#888888"><br>
    <pre cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</pre>
  </font></span></div>

<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" class="cremed">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank" class="cremed">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>