Started 1 mo 5 days ago
Took 5 hr 21 min on green-dragon-02

Success Build #14658 (Sep 8, 2019 12:44:56 PM)

  • : 371346
  • : 371342
  • : 371338
  • : 371154
  • : 371324
  • : 371250
  1. [X86] X86DAGToDAGISel::combineIncDecVector(): call getSplatBuildVector() manually

    As reported in post-commit review of r370327,
    there is some case where the code crashes.

    As discussed with Craig Topper, the problem is that getConstant()
    internally calls getSplatBuildVector(), so we don't insert
    the constant itself.

    If we do that manually we're good. (detail)
    by lebedevri
  2. [X86] Use DAG.getConstant instead of getZeroVector in combinePMULDQ.

    getZeroVector canonicalizes the type to vXi32, but that's a
    legalization action. We should use the most correct type if
    possible. (detail)
    by ctopper
  3. [DAGCombiner][X86][ARM] Teach visitMULO to fold multiplies with 0 to 0 and no carry.

    I modified the ARM test to use two inputs instead of 0 so the
    test hopefully still tests what was intended. (detail)
    by ctopper
  4. [X86] Teach materializeVectorConstant to not call getZeroVector/getOnesVector on the types we already have isel patterns for. (detail)
    by ctopper
  5. Move prop-sink branch to monorepo. (detail)
    by boga95
  6. [InstCombine] fold extract+insert into identity shuffle

    This is similar to the existing fold for splats added with:

    If we can adjust the shuffle mask to include another element
    in an identity mask (if it changes vector length, that's an
    extract/insert subvector operation in the backend), then that
    can eliminate extractelement/insertelement pairs in IR.

    All targets are expected to lower shuffles with identity masks
    efficiently. (detail)
    by spatel
  7. [NFC][InstSimplify] Some tests for dropping null check after uadd.with.overflow of non-null (PR43246)

    Name: C <= Y && Y != 0  -->  C <= Y  iff C != 0
    Pre: C != 0
      %y_is_nonnull = icmp ne i64 %y, 0
      %no_overflow = icmp ule i64 C, %y
      %r = and i1 %y_is_nonnull, %no_overflow
      %r = %no_overflow

    Name: C <= Y || Y != 0  -->  Y != 0  iff C != 0
    Pre: C != 0
      %y_is_nonnull = icmp ne i64 %y, 0
      %no_overflow = icmp ule i64 C, %y
      %r = or i1 %y_is_nonnull, %no_overflow
      %r = %y_is_nonnull

    Name: C > Y || Y == 0  -->  C > Y  iff C != 0
    Pre: C != 0
      %y_is_null = icmp eq i64 %y, 0
      %overflow = icmp ugt i64 C, %y
      %r = or i1 %y_is_null, %overflow
      %r = %overflow

    Name: C > Y && Y == 0  -->  Y == 0  iff C != 0
    Pre: C != 0
      %y_is_null = icmp eq i64 %y, 0
      %overflow = icmp ugt i64 C, %y
      %r = and i1 %y_is_null, %overflow
      %r = %y_is_null (detail)
    by lebedevri
  8. Enable LSan tests for NetBSD/i386 (detail)
    by kamil
  9. Stop marking 5 ASan tests as failing on NetBSD/i386

    Unexpected Passing Tests (4):
        AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage-reset.cpp
        AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage.cpp
        AddressSanitizer-i386-netbsd :: TestCases/Posix/interception-in-shared-lib-test.cpp
        AddressSanitizer-i386-netbsd :: TestCases/suppressions-library.cpp (detail)
    by kamil
  10. [ASan] Only run dlopen-mixed-c-cxx.c with static runtime

    This is what the original bug ( and the fix
    in have been about.
    With the dynamic runtime the test only passes when the asan library
    is linked against libstdc++: In contrast to libc++abi, it does not
    implement __cxa_rethrow_primary_exception so the regex matches the
    line saying that asan cannot intercept this function. Indeed, there
    is no message that the runtime failed to intercept  __cxa_throw.

    Differential Revision: (detail)
    by hahnfeld
  11. Enable leak-detection for NetBSD/amd64 in test/asan (detail)
    by kamil
  12. Do not intercept malloc_usable_size on NetBSD (detail)
    by kamil
  13. [DebugInfo][X86] Describe call site values for zero-valued imms

    Add zero-materializing XORs to X86's describeLoadedValue() hook in order
    to produce call site values.

    I have had to change the defs logic in collectCallSiteParameters() a bit
    to be able to describe the XORs. The XORs implicitly define $eflags,
    which would cause them to never be considered, due to a guard condition
    that I->getNumDefs() is one. I have changed that condition so that we
    now only consider instructions where a forwarded register overlaps with
    the instruction's single explicit define. We still need to collect the implicit
    defines of other forwarded registers to remove them from the work list.
    I'm not sure how to move towards supporting instructions with multiple
    explicit defines, cases where forwarded register are implicitly defined,
    and/or cases where an instruction produces values for multiple forwarded
    registers. Perhaps the describeLoadedValue() hook should take a register
    argument, and we then leave it up to the hook to describe the loaded
    value in that register? I have not yet encountered a situation where
    that would be necessary though.

    Reviewers: aprantl, vsk, djtodoro, NikolaPrica

    Reviewed By: vsk

    Subscribers: ychen, hiraditya, llvm-commits

    Tags: #debug-info, #llvm

    Differential Revision: (detail)
    by dstenb
  14. [NFC] Make the describeLoadedValue() hook return machine operand objects

    This changes the ParamLoadedValue pair which the describeLoadedValue()
    hook returns so that MachineOperand objects are returned instead of

    When describing call site values we may need to describe operands which
    are not part of the instruction. One such example is zero-materializing
    XORs on x86, which I have implemented support for in a child revision.
    Instead of having to return a pointer to an operand stored somewhere
    outside the instruction, start returning objects directly instead, as
    that simplifies the code.

    The MachineOperand class only holds POD members, and on x86-64 it is 32
    bytes large. That combined with copy elision means that the overhead of
    returning a machine operand object from the hook does not become very

    I benchmarked this on a 8-thread i7-8650U machine with 32 GB RAM. The
    benchmark consisted of building a clang 8.0 binary configured with:

      -DCMAKE_BUILD_TYPE=RelWithDebInfo \
      -DLLVM_USE_SANITIZER=Address \
      -DCMAKE_CXX_FLAGS="-Xclang -femit-debug-entry-values -stdlib=libc++"

    The average wall clock time increased by 4 seconds, from 62:05 to
    62:09, which is an 0.1% increase.

    Reviewers: aprantl, vsk, djtodoro, NikolaPrica

    Reviewed By: vsk

    Subscribers: hiraditya, ychen, llvm-commits

    Tags: #debug-info, #llvm

    Differential Revision: (detail)
    by dstenb

Started by timer (6 times)

This run spent:

  • 5 hr 34 min waiting;
  • 5 hr 21 min build duration;
  • 10 hr total from scheduled to completion.
Test Result (no failures)