Started 16 days ago
Took 1 hr 20 min on green-dragon-09

Success Build #17797 (Jun 10, 2019 11:38:02 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 362973
  • http://llvm.org/svn/llvm-project/cfe/trunk : 362965
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 362970
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 362745
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 362967
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 362939
Changes
  1. [llvm-objcopy] Fix SHT_GROUP ordering.

    Summary:
    When llvm-objcopy sorts sections during finalization, it only sorts based on the offset, which can cause the group section to come after the sections it contains. This causes link failures when using gold to link objects created by llvm-objcopy.

    Fix this for now by copying GNU objcopy's behavior of placing SHT_GROUP sections first. In the future, we may want to remove this sorting entirely to more closely preserve the input file layout.

    This fixes https://bugs.llvm.org/show_bug.cgi?id=42052.

    Reviewers: jakehehrlich, jhenderson, MaskRay, espindola, alexshap

    Reviewed By: MaskRay

    Subscribers: phuongtrang148993, emaste, arichardson, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D62620 (detail/ViewSVN)
    by rupprecht
  2. [Analysis] add unit test file for VectorUtils; NFC (detail/ViewSVN)
    by spatel
  3. Prepare for multi-exit LFTR [NFC]

    This change does the plumbing to wire an ExitingBB parameter through the LFTR implementation, and reorganizes the code to work in terms of a set of individual loop exits. Most of it is fairly obvious, but there's one key complexity which makes it worthy of consideration. The actual multi-exit LFTR patch is in D62625 for context.

    Specifically, it turns out the existing code uses the backedge taken count from before a IV is widened. Oddly, we can end up with a different (more expensive, but semantically equivelent) BE count for the loop when requerying after widening.  For the nestedIV example from elim-extend, we end up with the following BE counts:
    BEFORE: (-2 + (-1 * %innercount) + %limit)
    AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)

    This is the only test in tree which seems sensitive to this difference. The actual result of using the wider BETC on this example is that we actually produce slightly better code. :)

    In review, we decided to accept that test change.  This patch is structured to preserve the old behavior, but a separate change will immediate follow with the behavior change.  (I wanted it separate for problem attribution purposes.)

    Differential Revision: https://reviews.llvm.org/D62880 (detail/ViewSVN)
    by reames
  4. Add unused symbol to thunk files to force wholearchive inclusion

    These "dynamic_runtime_thunk" object files exist to create a weak alias
    from 'foo' to 'foo_dll' for all weak sanitizer runtime symbols. The weak
    aliases are implemented as /alternatename linker options in the
    .drective section, so they are not actually in the symbol table. In
    order to force the Visual C++ linker to load the object, even with
    -wholearchive:, we have to provide at least one external symbol. Once we
    do that, it will read the .drective sections and see the weak aliases.

    Fixes PR42074 (detail/ViewSVN)
    by rnk
  5. [ELF][llvm-objdump] Treat dynamic tag values as virtual addresses instead of offsets

    The ELF gABI requires the tag values of DT_REL, DT_RELA and DT_JMPREL to be
    treated as virtual addresses. They were treated as offsets. Fixes PR41832.

    Differential Revision: https://reviews.llvm.org/D62972 (detail/ViewSVN)
    by wolfgangp
  6. [RISCV] Replace map with set in getReqFeatures

    Summary:
    Use a set in getReqFeatures() in RISCVCompressInstEmitter instead of a map
    because the index we save is not needed.

    This also fixes bug 41666.

    Reviewers: llvm-commits, apazos, asb, nickdesaulniers

    Reviewed By: asb

    Subscribers: Jim, nickdesaulniers, rbar, johnrusso, simoncook, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D61412 (detail/ViewSVN)
    by sabuasal
  7. [libc++] Fix leading zeros in std::to_chars

    Summary:
    It is a bugfix proposal for https://bugs.llvm.org/show_bug.cgi?id=42166.

    `std::to_chars` appends leading zeros if input 64-bit value has 9, 10 or 11 digits.
    According to documentation `std::to_chars` must not append leading zeros:
    https://en.cppreference.com/w/cpp/utility/to_chars

    Changeset should not affect `std::to_chars` performance:
    http://quick-bench.com/CEpRs14xxA9WLvkXFtaJ3TWOVAg

    Unit test that `std::from_chars` supports compatibility for both `std::to_chars` outputs (previous and fixed one) already exists:
    https://github.com/llvm-mirror/libcxx/blob/1f60111b597e5cb80a4513ec86f79b7e137f7793/test/std/utilities/charconv/charconv.from.chars/integral.pass.cpp#L63

    Reviewers: lichray, mclow.lists, ldionne, EricWF

    Reviewed By: lichray, mclow.lists

    Subscribers: zoecarver, christof, dexonsmith, libcxx-commits

    Differential Revision: https://reviews.llvm.org/D63047 (detail/ViewSVN)
    by lichray
  8. [docs] Add 'git llvm revert' to getting started guide

    Summary: This documents `git llvm revert rNNNNNN` in the getting started guide for broader visibility.

    Reviewers: jyknight, mehdi_amini

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D63023 (detail/ViewSVN)
    by rupprecht
  9. [X86] Attempt to make the Intel core CPU inheritance a little more readable and maintainable

    The recently added cooperlake CPU has made our already ugly switch statement even worse. There's a CPU exclusion list around the bf16 feature in the cooper lake block. I worry that we'll have to keep adding new CPUs to that until bf16 intercepts a client space CPU. We have several other exclusion lists in other parts of the switch due to skylakeserver, cascadelake, and cooperlake not having sgx. Another for cannonlake not having clwb but having all other features from skx.

    This removes all these special ifs at the cost of some duplication of features and a goto. I've copied all of the skx features into either cannonlake or icelakeclient(for clwb). And pulled sklyakeserver, cascadelake, and cooperlake out of the main inheritance chain into their own chain. At the end of skylakeserver we merge back into the main chain at skylakeclient but below sgx. I think this is at least easier to follow.

    Differential Revision: https://reviews.llvm.org/D63018 (detail/ViewSVN)
    by ctopper
  10. [llvm-mca] Enable bottleneck analysis when flag -all-views is specified.

    Bottleneck Analysis is one of the many views available in llvm-mca. Therefore,
    it should be enabled when flag -all-views is passed in input to the tool. (detail/ViewSVN)
    by adibiagio
  11. [FastISel] Skip creating unnecessary vregs for arguments

    This behavior was added in r130928 for both FastISel and SD, and then
    disabled in r131156 for FastISel.

    This re-enables it for FastISel with the corresponding fix.

    This is triggered only when FastISel can't lower the arguments and falls
    back to SelectionDAG for it.

    FastISel contains a map of "register fixups" where at the end of the
    selection phase it replaces all uses of a register with another
    register that FastISel sometimes pre-assigned. Code at the end of
    SelectionDAGISel::runOnMachineFunction is doing the replacement at the
    very end of the function, while other pieces that come in before that
    look through the MachineFunction and assume everything is done. In this
    case, the real issue is that the code emitting COPY instructions for the
    liveins (physreg to vreg) (EmitLiveInCopies) is checking if the vreg
    assigned to the physreg is used, and if it's not, it will skip the COPY.
    If a register wasn't replaced with its assigned fixup yet, the copy will
    be skipped and we'll end up with uses of undefined registers.

    This fix moves the replacement of registers before the emission of
    copies for the live-ins.

    The initial motivation for this fix is to enable tail calls for
    swiftself functions, which were blocked because we couldn't prove that
    the swiftself argument (which is callee-save) comes from a function
    argument (live-in), because there was an extra copy (vreg to vreg).

    A few tests are affected by this:

    * llvm/test/CodeGen/AArch64/swifterror.ll: we used to spill x21
    (callee-save) but never reload it because it's attached to the return.
    We now don't even spill it anymore.
    * llvm/test/CodeGen/*/swiftself.ll: we tail-call now.
    * llvm/test/CodeGen/AMDGPU/mubuf-legalize-operands.ll: I believe this
    test was not really testing the right thing, but it worked because the
    same registers were re-used.
    * llvm/test/CodeGen/ARM/cmpxchg-O0.ll: regalloc changes
    * llvm/test/CodeGen/ARM/swifterror.ll: get rid of a copy
    * llvm/test/CodeGen/Mips/*: get rid of spills and copies
    * llvm/test/CodeGen/SystemZ/swift-return.ll: smaller stack
    * llvm/test/CodeGen/X86/atomic-unordered.ll: smaller stack
    * llvm/test/CodeGen/X86/swifterror.ll: same as AArch64
    * llvm/test/DebugInfo/X86/dbg-declare-arg.ll: stack size changed

    Differential Revision: https://reviews.llvm.org/D62361 (detail/ViewSVN)
    by thegameg

Started by upstream project Clang Stage 1: cmake, RA, using system compiler build number 57403
originally caused by:

Started by upstream project Clang Stage 1: cmake, RA, using system compiler build number 57404
originally caused by:

Started by upstream project Clang Stage 1: cmake, RA, using system compiler build number 57405
originally caused by:

Started by upstream project Clang Stage 1: cmake, RA, using system compiler build number 57406
originally caused by:

This run spent:

  • 1 hr 23 min waiting;
  • 1 hr 20 min build duration;
  • 2 hr 44 min total from scheduled to completion.
LLVM/Clang Warnings: 0 warnings.
  • No warnings since build 17,762.
  • Still 70 days before reaching the previous zero warnings highscore.