Started 2 yr 3 mo ago
Took 1 hr 13 min on green-dragon-13

Success Build #319 (Aug 11, 2017 12:12:01 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 310697
  • http://llvm.org/svn/llvm-project/cfe/trunk : 310694
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 310651
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 303903
  • http://llvm.org/svn/llvm-project/zorg/trunk : 310557
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 310487
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 310669
Changes
  1. [IfConversion] Maintain the CFG when predicating/merging blocks in IfConvert*

    Summary:
    This fixes PR32721 in IfConvertTriangle and possible similar problems in
    IfConvertSimple, IfConvertDiamond and IfConvertForkedDiamond.

    In PR32721 we had a triangle

       EBB
       | \
       |  |
       | TBB
       |  /
       FBB

    where FBB didn't have any successors at all since it ended with an
    unconditional return. Then TBB and FBB were be merged into EBB, but EBB
    would still keep its successors, and the use of analyzeBranch and
    CorrectExtraCFGEdges wouldn't help to remove them since the return
    instruction is not analyzable (at least not on ARM).

    The edge updating code and branch probability updating code is now pushed
    into MergeBlocks() which allows us to share the same update logic between
    more callsites. This lets us remove several dependencies on analyzeBranch
    and completely eliminate RemoveExtraEdges.

    One thing that showed up with this patch was that IfConversion sometimes
    left a successor with 0% probability even if there was no branch or
    fallthrough to the successor.

    One such example from the test case ifcvt_bad_zero_prob_succ.mir. The
    indirect branch tBRIND can only jump to bb.1, but without the patch we
    got:

      bb.0:
        successors: %bb.1(0x80000000)

      bb.1:
        successors: %bb.1(0x80000000), %bb.2(0x00000000)
        tBRIND %r1, 1, %cpsr
        B %bb.1

      bb.2:

    There is no way to jump from bb.1 to bb2, but still there is a 0% edge
    from bb.1 to bb.2.

    With the patch applied we instead get the expected:

      bb.0:
        successors: %bb.1(0x80000000)

      bb.1:
        successors: %bb.1(0x80000000)
        tBRIND %r1, 1, %cpsr
        B %bb.1

    Since bb.2 had no predecessor at all, it was removed.

    Several testcases had to be updated due to this since the removed
    successor made the "Branch Probability Basic Block Placement" pass
    sometimes place blocks in a different order.

    Finally added a couple of new test cases:

    * PR32721_ifcvt_triangle_unanalyzable.mir:
      Regression test for the original problem dexcribed in PR 32721.

    * ifcvt_triangleWoCvtToNextEdge.mir:
      Regression test for problem that caused a revert of my first attempt
      to solve PR 32721.

    * ifcvt_simple_bad_zero_prob_succ.mir:
      Test case showing the problem where a wrong successor with 0% probability
      was previously left.

    * ifcvt_[diamond|forked_diamond|simple]_unanalyzable.mir
      Very simple test cases for the simple and (forked) diamond cases
      involving unanalyzable branches that can be nice to have as a base if
      wanting to write more complicated tests.

    Reviewers: iteratee, MatzeB, grosser, kparzysz

    Reviewed By: kparzysz

    Subscribers: kbarton, davide, aemerson, nemanjai, javed.absar, kristof.beyls, llvm-commits

    Differential Revision: https://reviews.llvm.org/D34099 (detail)
    by uabelho
  2. [PM] Switch the CGSCC debug messages to use the standard LLVM debug
    printing techniques with a DEBUG_TYPE controlling them.

    It was a mistake to start re-purposing the pass manager `DebugLogging`
    variable for generic debug printing -- those logs are intended to be
    very minimal and primarily used for testing. More detailed and
    comprehensive logging doesn't make sense there (it would only make for
    brittle tests).

    Moreover, we kept forgetting to propagate the `DebugLogging` variable to
    various places making it also ineffective and/or unavailable. Switching
    to `DEBUG_TYPE` makes this a non-issue. (detail)
    by chandlerc

Started by timer (2 times)

This run spent:

  • 1 hr 1 min waiting;
  • 1 hr 13 min build duration;
  • 2 hr 14 min total from scheduled to completion.
Test Result (no failures)