Started 29 days ago
Took 4 hr 23 min on green-dragon-02

Failed Build #14896 (Oct 16, 2019 8:57:01 AM)

  • : 375009
  • : 375003
  • : 374977
  • : 374976
  • : 374854
  • : 374982
  1. [Codegen] Adjust saturation test. NFC.

    Add some extra sat tests and adjust some of the existing tests to use signext where it would naturally be. (detail)
    by dmgreen
  2. [Remarks] Add support for prepending a path to external files

    This helps with testing and debugging for paths that are assumed

    It also uses a FileError to provide the file path it's trying to open. (detail)
    by thegameg
  3. bpf: fix wrong truncation elimination when there is back-edge/loop

    Currently, BPF backend is doing truncation elimination. If one truncation
    is performed on a value defined by narrow loads, then it could be redundant
    given BPF loads zero extend the destination register implicitly.

    When the definition of the truncated value is a merging value (PHI node)
    that could come from different code paths, then checks need to be done on
    all possible code paths.

    Above described optimization was introduced as r306685, however it doesn't
    work when there is back-edge, for example when loop is used inside BPF

    For example for the following code, a zero-extended value should be stored
    into b[i], but the "and reg, 0xffff" is wrongly eliminated which then
    generates corrupted data.

    void cal1(unsigned short *a, unsigned long *b, unsigned int k)
      unsigned short e;

      e = *a;
      for (unsigned int i = 0; i < k; i++) {
        b[i] = e;
        e = ~e;

    The reason is r306685 was trying to do the PHI node checks inside isel
    DAG2DAG phase, and the checks are done on MachineInstr. This is actually
    wrong, because MachineInstr is being built during isel phase and the
    associated information is not completed yet. A quick search shows none
    target other than BPF is access MachineInstr info during isel phase.

    For an PHI node, when you reached it during isel phase, it may have all
    predecessors linked, but not successors. It seems successors are linked to
    PHI node only when doing SelectionDAGISel::FinishBasicBlock and this
    happens later than PreprocessISelDAG hook.

    Previously, BPF program doesn't allow loop, there is probably the reason
    why this bug was not exposed.

    This patch therefore fixes the bug by the following approach:
    - The existing truncation elimination code and the associated
       "load_to_vreg_" records are removed.
    - Instead, implement truncation elimination using MachineSSA pass, this
       is where all information are built, and keep the pass together with other
       similar peephole optimizations inside BPFMIPeephole.cpp. Redundant move
       elimination logic is updated accordingly.
    - Unit testcase included + no compilation errors for kernel BPF selftest.

    Patch Review
    Patch was sent to and reviewed by BPF community at:

    Reported-by: David Beckett <>
    Reviewed-by: Yonghong Song <>
    Signed-off-by: Jiong Wang <> (detail)
    by jiwang
  4. [RISCV] Add MachineInstr immediate verification

    This patch implements the `TargetInstrInfo::verifyInstruction` hook for RISC-V. Currently the hook verifies the machine instruction's immediate operands, to check if the immediates are within the expected bounds. Without the hook invalid immediates are not detected except when doing assembly parsing, so they are silently emitted (including being truncated when emitting object code).

    The bounds information is specified in tablegen by using the `OperandType` definition, which sets the `MCOperandInfo`'s `OperandType` field. Several RISC-V-specific immediate operand types were created, which extend the `MCInstrDesc`'s `OperandType` `enum`.

    To have the hook called with `llc` pass it the `-verify-machineinstrs` option. For Clang add the cmake build config `-DLLVM_ENABLE_EXPENSIVE_CHECKS=True`, or temporarily patch `TargetPassConfig::addVerifyPass`.

    Review concerns:

    - The patch adds immediate operand type checks that cover at least the base ISA. There are several other operand types for the C extension and one type for the F/D extensions that were left out of this initial patch because they introduced further design concerns that I felt were best evaluated separately.

    - Invalid register classes (e.g. passing a GPR register where a GPRC is expected) are already caught, so were not included.

    - This design makes the more abstract `MachineInstr` verification depend on MC layer definitions, which arguably is not the cleanest design, but is in line with how things are done in other parts of the target and LLVM in general.

    - There is some duplication of logic already present in the `MCOperandPredicate`s. Since the `MachineInstr` and `MCInstr` notions of immediates are fundamentally different, this is currently necessary.

    Reviewers: asb, lenary

    Reviewed By: lenary

    Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by luismarques
  5. [AMDGPU] Fix-up cases where writelane has 2 SGPR operands

    Even though writelane doesn't have the same constraints as other valu
    instructions it still can't violate the >1 SGPR operand constraint

    Due to later register propagation (e.g. fixing up vgpr operands via
    readfirstlane) changing writelane to only have a single SGPR is tricky.

    This implementation puts a new check after SIFixSGPRCopies that prevents
    multiple SGPRs being used in any writelane instructions.

    The algorithm used is to check for trivial copy prop of suitable constants into
    one of the SGPR operands and perform that if possible. If this isn't possible
    put an explicit copy of Src1 SGPR into M0 and use that instead (this is
    allowable for writelane as the constraint is for SGPR read-port and not
    constant-bus access).

    Reviewers: rampitec, tpr, arsenm, nhaehnle

    Reviewed By: rampitec, arsenm, nhaehnle

    Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, mgorny, yaxunl, tpr, t-tye, llvm-commits

    Tags: #llvm

    Differential Revision:

    Change-Id: Ic7553fa57440f208d4dbc4794fc24345d7e0e9ea (detail)
    by dstuttard
  6. [libTooling] Fix r374962: add more Transformer forwarding decls.

    The move to a new, single namespace in r374962 left out some type definitions
    from the old namespace and resulted in one naming conflict (`text`).  This
    revision adds aliases for those definitions and removes one of the `text`
    functions from the new namespace.

    Reviewers: alexfh

    Subscribers: cfe-commits

    Tags: #clang

    Differential Revision: (detail)
    by ymandel
  7. [llvm-ar] Make paths case insensitive when on windows

    When on windows gnu-ar treats member names as case insensitive. This
    commit implements the same behaviour.

    Differential Revision: (detail)
    by gbreynoo
  8. [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

    Since `-mfloat-abi=soft` is taken to mean turning off all uses of the
    FP registers, it should turn off the MVE vector instructions as well
    as NEON and scalar FP. But it wasn't doing so.

    So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft`
    would cause the underlying LLVM to //not// support MVE (because it
    knows the real target feature relationships and turned off MVE when
    the `fpregs` feature was removed), but the clang layer still thought
    it //was// supported, and would misleadingly define the feature macro

    The ARM driver code already has a long list of feature names to turn
    off when `-mfloat-abi=soft` is selected. The fix is to add the missing
    entries `mve` and `mve.fp` to that list.

    Reviewers: dmgreen

    Subscribers: kristof.beyls, cfe-commits

    Tags: #clang

    Differential Revision: (detail)
    by statham
  9. [Alignment][NFC] Optimize alignTo

    Summary: A small optimization suggested by jakehehrlich@ in D64790.

    Reviewers: jakehehrlich, courbet

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by gchatelet
  10. RedirectingFileSystem::openFileForRead - replace bitwise & with boolean && to fix warning

    Seems to be just a typo - now matches other instances which do something similar (detail)
    by rksimon
  11. RealFile - fix self-initialization warning in constructor. (detail)
    by rksimon
  12. [InstCombine][AMDGPU] Fix crash with v3i16/v3f16 buffer intrinsics

    This is something of a workaround to avoid a crash later on in type
    legalizer (WidenVectorResult()).
    Also added some f16 tests, including a non-working v3f16 case with
    a FIXME.

    Reviewers: arsenm, tpr, nhaehnle

    Reviewed By: arsenm

    Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by Piotr Sobczak

Started by timer (5 times)

This run spent:

  • 4 hr 46 min waiting;
  • 4 hr 23 min build duration;
  • 9 hr 9 min total from scheduled to completion.

Identified problems

Regression test failed

This build failed because a regression test in the test suite FAILed. See the test report for details.
Indication 1

Ninja target failed

Below is a link to the first failed ninja target.
Indication 2

Missing test results

The test result file Jenkins is looking for does not exist after the build.
Indication 3