Started 3 mo 24 days ago
Took 10 hr on green-dragon-15

Success Build #4175 (Jul 20, 2019 6:24:28 PM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 366646
  • http://llvm.org/svn/llvm-project/cfe/trunk : 366645
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 366638
  • http://llvm.org/svn/llvm-project/lld/trunk : 366644
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 364589
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 366606
  • http://llvm.org/svn/llvm-project/test-suite/trunk : 366290
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 366577
  • http://llvm.org/svn/llvm-project/polly/trunk : 366510
Changes
  1. gn build: Merge r366622 (detail/ViewSVN)
    by nico
  2. [Clang] Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer'
    with '-mframe-pointer'

    After D56351 and D64294, frame pointer handling is migrated to tri-state
    (all, non-leaf, none) in clang driver and on the function attribute.
    This patch makes the frame pointer handling cc1 option tri-state.

    Reviewers: chandlerc, rnk, t.p.northover, MaskRay

    Reviewed By: MaskRay

    Differential Revision: https://reviews.llvm.org/D56353 (detail/ViewSVN)
    by yuanfang
  3. [ELF] Support explicitly overriding relocation model in LTO

    lld currently selects the relocation model automatically depending on
    the link flags specified, but in some cases it'd be useful to allow
    explicitly overriding the relocation model using a flag. (detail/ViewSVN)
    by phosek
  4. [NFC][InstCombine] Autogenerate a few tests (detail/ViewSVN)
    by lebedevri
  5. [NFC][InstCombine] Add srem-by-signbit tests - still can fold to bittest

    https://rise4fun.com/Alive/IIeS (detail/ViewSVN)
    by lebedevri
  6. [NFC][Codegen][X86][AArch64] Add "(x s% C) == 0" tests

    Much like with `urem`, the same optimization (albeit with slightly
    different algorithm) applies for the signed case, too.

    I'm simply copying the test coverage from `urem` case for now,
    i believe it should be (close to?) sufficient. (detail/ViewSVN)
    by lebedevri
  7. Fix asan infinite loop on undefined symbol

    Fix llvm#39641

    Recommit of r366413

    Differential Revision: https://reviews.llvm.org/D63877

    llvm-svn: 366632 (detail/ViewSVN)
    by serge_sans_paille
  8. [Codegen][SelectionDAG] X u% C == 0 fold: non-splat vector improvements

    Summary:
    Four things here:
    1. Generalize the fold to handle non-splat divisors. Reasonably trivial.
    2. Unban power-of-two divisors. I don't see any reason why they should
       be illegal.
       * There is no ban in Hacker's Delight
       * I think the ban came from the same bug that caused the miscompile
          in the base patch - in `floor((2^W - 1) / D)` we were dividing by
          `D0` instead of `D`, and we **were** ensuring that `D0` is not `1`,
          which made sense.
    3. Unban `1` divisors. I no longer believe Hacker's Delight actually says
       that the fold is invalid for `D = 0`. Further considerations:
       * We know that
         * `(X u% 1) == 0`  can be constant-folded to `1`,
         * `(X u% 1) != 0`  can be constant-folded to `0`,
       *  Also, we know that
         * `X u<= -1` can be constant-folded to `1`,
         * `X u>  -1` can be constant-folded to `0`,
       * https://godbolt.org/z/7jnZJX https://rise4fun.com/Alive/oF6p
       * We know will end up with the following:
           `(setule/setugt (rotr (mul N, P), K), Q)`
       * Therefore, for given new DAG nodes and comparison predicates
         (`ule`/`ugt`), we will still produce the correct answer if:
         `Q` is a all-ones constant; and both `P` and `K` are *anything*
         other than `undef`.
       * The fold will indeed produce `Q = all-ones`.
    4. Try to re-splat the `P` and `K` vectors - we don't care about
       their values for the lanes where divisor was `1`.

    Reviewers: RKSimon, hermord, craig.topper, spatel, xbolva00

    Reviewed By: RKSimon

    Subscribers: hiraditya, javed.absar, dexonsmith, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D63963 (detail/ViewSVN)
    by lebedevri
  9. [X86][SSE] Use PSADBW to improve vXi8 sum reduction (PR42674)

    As detailed on PR42674, we can reduce a vXi8 down until we have the final <8 x i8>, and then use PSADBW with zero, to sum those values. We then extract the bottom i8, discarding any overflow from the upper bits of the i16 result. (detail/ViewSVN)
    by rksimon

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

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

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

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

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

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

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

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

This run spent:

  • 9 hr 53 min waiting;
  • 10 hr build duration;
  • 20 hr total from scheduled to completion.
LLVM/Clang Warnings: 12 warnings.