Started 16 days ago
Took 9 min 29 sec

Success Build clang-r362968-t57407-b57407.tar.gz (Jun 10, 2019 11:29:00 AM)

Issues

No known issues detected

Build Log

Revision: 362564
Changes
  1. [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)
    by sabuasal
  2. [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)
    by rupprecht
  3. [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)
    by adibiagio
  4. [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)
    by thegameg
Revision: 362564
Changes
  1. [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)
    by ctopper
  2. [WebAssembly] Cleanup toolchain test files. NFC.

    Summary: Split up long lines to improve test readability.

    Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D63081 (detail)
    by sbc
Revision: 362564
Changes
  1. [scudo][standalone] Introduce the thread specific data structures

    Summary:
    This CL adds the structures dealing with thread specific data for the
    allocator. This includes the thread specific data structure itself and
    two registries for said structures: an exclusive one, where each thread
    will have its own TSD struct, and a shared one, where a pool of TSD
    structs will be shared by all threads, with dynamic reassignment at
    runtime based on contention.

    This departs from the current Scudo implementation: we intend to make
    the Registry a template parameter of the allocator (as opposed to a
    single global entity), allowing various allocators to coexist with
    different TSD registry models. As a result, TSD registry and Allocator
    are tightly coupled.

    This also corrects a couple of things in other files that I noticed
    while adding this.

    Reviewers: eugenis, vitalybuka, morehouse, hctim

    Reviewed By: morehouse

    Subscribers: srhines, mgorny, delcypher, jfb, #sanitizers, llvm-commits

    Tags: #llvm, #sanitizers

    Differential Revision: https://reviews.llvm.org/D62258 (detail)
    by cryptoad
Revision: 362564
Changes
  1. [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)
    by lichray

Started by upstream project relay-lnt-ctmark build number 8586
originally caused by:

This run spent:

  • 8.9 sec waiting;
  • 9 min 29 sec build duration;
  • 9 min 38 sec total from scheduled to completion.