Started 1 mo 14 days ago
Took 17 hr on green-dragon-09

Failed Build #5469 (Sep 9, 2019 12:38:48 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 371366
  • http://llvm.org/svn/llvm-project/cfe/trunk : 371342
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 371354
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 364589
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 371324
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 371250
Changes
  1. [X86] Add broadcast load unfold support for smin/umin/smax/umax. (detail/ViewSVN)
    by ctopper
  2. [X86] Add broadcast load unfolding tests for smin/umin/smax/smin. (detail/ViewSVN)
    by ctopper
  3. AMDGPU: Remove pointless wrapper nodes for init.exec intrinsics (detail/ViewSVN)
    by arsenm
  4. [X86] Add broadcast load unfolding support for VMAXPS/PD and VMINPS/PD. (detail/ViewSVN)
    by ctopper
  5. [X86] Add broadcast load unfolding tests for vmaxps/pd and vminps/pd (detail/ViewSVN)
    by ctopper
  6. [X86] Add fp128 test cases for ceil/floor/trunc/nearbyint/rint/round libcalls. (detail/ViewSVN)
    by ctopper
  7. [MachineCopyPropagation] Remove redundant copies after TailDup via machine-cp

    Summary:
    After tailduplication, we have redundant copies. We can remove these
    copies in machine-cp if it's safe to, i.e.
    ```
    $reg0 = OP ...
    ... <<< No read or clobber of $reg0 and $reg1
    $reg1 = COPY $reg0 <<< $reg0 is killed
    ...
    <RET>
    ```
    will be transformed to
    ```
    $reg1 = OP ...
    ...
    <RET>
    ```

    Differential Revision: https://reviews.llvm.org/D65267 (detail/ViewSVN)
    by lkail
  8. [X86] Add test cases for fptoui/fptosi/sitofp/uitofp between fp128 and i128. (detail/ViewSVN)
    by ctopper
  9. [X86] Use xorps to create fp128 +0.0 constants.

    This matches what we do for f32/f64. gcc also does this for fp128. (detail/ViewSVN)
    by ctopper
  10. [X86] Add avx and avx512f RUN lines to fp128-cast.ll (detail/ViewSVN)
    by ctopper
  11. Relax opcode checks in test to check for only a number instead of a specific number. (detail/ViewSVN)
    by dyung
  12. Enable LSan for NetBSD/i386 in test/asan/lit.cfg.py (detail/ViewSVN)
    by kamil
  13. [X86][SSE] SimplifyDemandedVectorEltsForTargetNode - add faux shuffle support.

    This patch decodes target and faux shuffles with getTargetShuffleInputs - a reduced version of resolveTargetShuffleInputs that doesn't resolve SM_SentinelZero cases, so we can correctly remove zero vectors if they aren't demanded. (detail/ViewSVN)
    by rksimon
  14. [InstCombine][NFC] Some tests for usub overflow+nonzero check improvement (PR43251)

    https://rise4fun.com/Alive/kHq

    https://bugs.llvm.org/show_bug.cgi?id=43251 (detail/ViewSVN)
    by lebedevri
  15. [X86] Add a hack to combineVSelectWithAllOnesOrZeros to turn selects with two zero/undef vector inputs into an all zeroes vector.

    If the two zero vectors have undefs in different places they
    won't get combined by simplifySelect.

    This fixes a regression from an earlier commit. (detail/ViewSVN)
    by ctopper
  16. [X86] Remove call to getZeroVector from materializeVectorConstant. Add isel patterns for zero vectors with all types.

    The change to avx512-vec-cmp.ll is a regression, but should be
    easy to fix. It occurs because the getZeroVector call was
    canonicalizing both sides to the same node, then SimplifySelect
    was able to simplify it. But since only called getZeroVector
    on some VTs this isn't a robust way to combine this.

    The change to vector-shuffle-combining-ssse3.ll is more
    instructions, but removes a constant pool load so its unclear
    if its a regression or not. (detail/ViewSVN)
    by ctopper
  17. [InstSimplify] simplifyUnsignedRangeCheck(): if we know that X != 0, handle more cases (PR43246)

    Summary:
    This is motivated by D67122 sanitizer check enhancement.
    That patch seemingly worsens `-fsanitize=pointer-overflow`
    overhead from 25% to 50%, which strongly implies missing folds.

    In this particular case, given
    ```
    char* test(char& base, unsigned long offset) {
      return &base + offset;
    }
    ```
    it will end up producing something like
    https://godbolt.org/z/LK5-iH
    which after optimizations reduces down to roughly
    ```
    define i1 @t0(i8* nonnull %base, i64 %offset) {
      %base_int = ptrtoint i8* %base to i64
      %adjusted = add i64 %base_int, %offset
      %non_null_after_adjustment = icmp ne i64 %adjusted, 0
      %no_overflow_during_adjustment = icmp uge i64 %adjusted, %base_int
      %res = and i1 %non_null_after_adjustment, %no_overflow_during_adjustment
      ret i1 %res
    }
    ```
    Without D67122 there was no `%non_null_after_adjustment`,
    and in this particular case we can get rid of the overhead:

    Here we add some offset to a non-null pointer,
    and check that the result does not overflow and is not a null pointer.
    But since the base pointer is already non-null, and we check for overflow,
    that overflow check will already catch the null pointer,
    so the separate null check is redundant and can be dropped.

    Alive proofs:
    https://rise4fun.com/Alive/WRzq

    There are more patterns of "unsigned-add-with-overflow", they are not handled here,
    but this is the main pattern, that we currently consider canonical,
    so it makes sense to handle it.

    https://bugs.llvm.org/show_bug.cgi?id=43246

    Reviewers: spatel, nikic, vsk

    Reviewed By: spatel

    Subscribers: hiraditya, llvm-commits, reames

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D67332 (detail/ViewSVN)
    by lebedevri
  18. [InstCombine] add tests for icmp with srem operand; NFC (detail/ViewSVN)
    by spatel
  19. [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/ViewSVN)
    by lebedevri
  20. [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/ViewSVN)
    by ctopper
  21. [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/ViewSVN)
    by ctopper
  22. [X86] Teach materializeVectorConstant to not call getZeroVector/getOnesVector on the types we already have isel patterns for. (detail/ViewSVN)
    by ctopper
  23. Move prop-sink branch to monorepo. (detail/ViewSVN)
    by boga95
  24. [InstCombine] fold extract+insert into identity shuffle

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

    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/ViewSVN)
    by spatel
  25. [NFC][InstSimplify] Some tests for dropping null check after uadd.with.overflow of non-null (PR43246)

    https://rise4fun.com/Alive/WRzq

    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

    https://bugs.llvm.org/show_bug.cgi?id=43246 (detail/ViewSVN)
    by lebedevri
  26. Enable LSan tests for NetBSD/i386 (detail/ViewSVN)
    by kamil
  27. 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/ViewSVN)
    by kamil
  28. [ASan] Only run dlopen-mixed-c-cxx.c with static runtime

    This is what the original bug (http://llvm.org/PR39641) and the fix
    in https://reviews.llvm.org/D63877 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: https://reviews.llvm.org/D67298 (detail/ViewSVN)
    by hahnfeld
  29. Enable leak-detection for NetBSD/amd64 in test/asan (detail/ViewSVN)
    by kamil
  30. Do not intercept malloc_usable_size on NetBSD (detail/ViewSVN)
    by kamil
  31. [DebugInfo][X86] Describe call site values for zero-valued imms

    Summary:
    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: https://reviews.llvm.org/D67225 (detail/ViewSVN)
    by dstenb
  32. [NFC] Make the describeLoadedValue() hook return machine operand objects

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

    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
    large.

    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_TARGETS_TO_BUILD=X86 \
      -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: https://reviews.llvm.org/D67261 (detail/ViewSVN)
    by dstenb

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18278
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18279
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18280
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18281
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18282
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18283
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18284
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18285
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18286
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18287
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18288
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18289
originally caused by:

Started by upstream project Clang Stage 2: cmake, R -g Tsan, using Stage 1 RA build number 18290
originally caused by:

This run spent:

  • 16 hr waiting;
  • 17 hr build duration;
  • 1 day 10 hr 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

Compile Error

This build failed because of a compile error. Below is a list of all errors in the build log:
Indication 2

Ninja target failed

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

Missing test results

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