Started 17 days ago
Took 4 hr 46 min on green-dragon-20

Success Build #18181 (Jun 10, 2019 1:23:48 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 362921
  • http://llvm.org/svn/llvm-project/cfe/trunk : 362887
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 362859
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 362745
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 362866
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 362811
Changes
  1. [DAGCombine] Match a pattern where a wide type scalar value is stored by several narrow stores
    This opportunity is found from spec 2017 557.xz_r. And it is used by the sha encrypt/decrypt. See sha-2/sha512.c

    static void store64(u64 x, unsigned char* y)
    {
        for(int i = 0; i != 8; ++i)
            y[i] = (x >> ((7-i) * 8)) & 255;
    }

    static u64 load64(const unsigned char* y)
    {
        u64 res = 0;
        for(int i = 0; i != 8; ++i)
            res |= (u64)(y[i]) << ((7-i) * 8);
        return res;
    }
    The load64 has been implemented by https://reviews.llvm.org/D26149
    This patch is trying to implement the store pattern.

    Match a pattern where a wide type scalar value is stored by several narrow
    stores. Fold it into a single store or a BSWAP and a store if the targets
    supports it.

    Assuming little endian target:
    i8 *p = ...
    i32 val = ...
    p[0] = (val >> 0) & 0xFF;
    p[1] = (val >> 8) & 0xFF;
    p[2] = (val >> 16) & 0xFF;
    p[3] = (val >> 24) & 0xFF;

    >
    *((i32)p) = val;

    i8 *p = ...
    i32 val = ...
    p[0] = (val >> 24) & 0xFF;
    p[1] = (val >> 16) & 0xFF;
    p[2] = (val >> 8) & 0xFF;
    p[3] = (val >> 0) & 0xFF;

    >
    *((i32)p) = BSWAP(val);

    Differential Revision: https://reviews.llvm.org/D62897 (detail/ViewSVN)
    by qshanz
  2. [X86] When promoting i16 compare with immediate to i32, try to use sign_extend for eq/ne if the input is truncated from a type with enough sign its.

    Summary:
    Our default behavior is to use sign_extend for signed comparisons and zero_extend for everything else. But for equality we have the freedom to use either extension. If we can prove the input has been truncated from something with enough sign bits, we can use sign_extend instead and let DAG combine optimize it out. A similar rule is used by type legalization in LegalizeIntegerTypes.

    This gets rid of the movzx in PR42189. The immediate will still take 4 bytes instead of the 2 bytes plus 0x66 prefix a cmp di, 32767 would get, but it avoids a length changing prefix.

    Reviewers: RKSimon, spatel, xbolva00

    Reviewed By: xbolva00

    Subscribers: hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D63032 (detail/ViewSVN)
    by ctopper
  3. [X86] Disable f32->f64 extload when sse2 is enabled

    Summary:
    We can only use the memory form of cvtss2sd under optsize due to a partial register update. So previously we were emitting 2 instructions for extload when optimizing for speed. Also due to a late optimization in preprocessiseldag we had to handle (fpextend (loadf32)) under optsize.

    This patch forces extload to expand so that it will always be in the (fpextend (loadf32)) form during isel. And when optimizing for speed we can just let each of those pieces select an instruction independently.

    Reviewers: spatel, RKSimon

    Reviewed By: RKSimon

    Subscribers: hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D62710 (detail/ViewSVN)
    by ctopper
  4. Do not derive no-recurse attribute if function does not have exact definition.
    This is fix for https://bugs.llvm.org/show_bug.cgi?id=41336

    Reviewers: jdoerfert
    Reviewed by: jdoerfert

    Differential Revision: https://reviews.llvm.org/D63045 (detail/ViewSVN)
    by vivekvpandya
  5. [NFC] Test if commit access granted. (detail/ViewSVN)
    by lkail

Started by upstream project clang-stage2-Rthinlto_relay build number 1587
originally caused by:

This run spent:

  • 1 ms waiting;
  • 4 hr 46 min build duration;
  • 4 hr 46 min total from scheduled to completion.
Cobol Warnings: 0 warnings.
  • No warnings since build 10,378.
  • New zero warnings highscore: no warnings for 376 days!
Test Result (no failures)