Started 16 days ago
Took 1 hr 20 min on green-dragon-09

Success Build #17795 (Jun 10, 2019 8:06:54 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 362947
  • http://llvm.org/svn/llvm-project/cfe/trunk : 362944
  • 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 : 362939
Changes
  1. [IRBuilder] Add CreateFNegFMF(...) to the IRBuilder

    Differential Revision: https://reviews.llvm.org/D62521 (detail/ViewSVN)
    by mcinally
  2. [InstCombine] fix bug in canonicalization to fabs()

    Forgot to translate the predicate clauses in rL362943. (detail/ViewSVN)
    by spatel
  3. Revert "[CodeComplete] Improve overload handling for C++ qualified and ref-qualified methods."

    This reverts commit r362924, which causes a double-free of ShadowMapEntry. (detail/ViewSVN)
    by sammccall
  4. [InstCombine] change canonicalization to fabs() to use FMF on fsub

    Similar to rL362909:
    This isn't the ideal fix (use FMF on the select), but it's still an
    improvement until we have better FMF propagation to selects and other
    FP math operators.

    I don't think there's much risk of regression from this change by
    not including the FMF on the fcmp any more. The nsz/nnan FMF
    should be the same on the fcmp and the fsub because they have the
    same operand. (detail/ViewSVN)
    by spatel
  5. [ARM] Disallow PC, and optionally SP, in VMOVRH and VMOVHR.

    Arm v8.1-M supports the VMOV instructions that move a half-precision
    value to and from a GPR, but not if the GPR is SP or PC.

    To fix this, I've changed those instructions to use the rGPR register
    class instead of GPR. rGPR always excludes PC, and it excludes SP
    except in the presence of the HasV8Ops target feature (i.e. Arm v8-A).
    So the effect is that VMOV.F16 to and from PC is now illegal
    everywhere, but VMOV.F16 to and from SP is illegal only on non-v8-A
    cores (which I believe is all as it should be).

    Reviewers: dmgreen, samparker, SjoerdMeijer, ostannard

    Reviewed By: ostannard

    Subscribers: ostannard, javed.absar, kristof.beyls, hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D60704 (detail/ViewSVN)
    by statham
  6. [ExecutionEngine] Add UnaryOperator visitor to the interpreter

    This is to support the unary FNeg instruction.

    Differential Revision: https://reviews.llvm.org/D62881 (detail/ViewSVN)
    by mcinally
  7. [yaml2obj] - Remove TODOs from dynsymtab-implicit-sections-size-content.yaml. NFCI.

    Now when https://bugs.llvm.org/show_bug.cgi?id=42215 is fixed,
    we can remove these TODOs. (detail/ViewSVN)
    by grimar
  8. [clangd] Revamp textDocument/onTypeFormatting.

    Summary:
    The existing implementation (which triggers on }) is fairly simple and
    has flaws:
    - doesn't trigger frequently/regularly enough (particularly in editors that type the }
    for you)
    - often reformats too much code around the edit
    - has jarring cases that I don't have clear ideas for fixing

    This implementation is designed to trigger on newline, which feels to me more
    intuitive than } or ;.
    It does have allow for reformatting after other characters - it has a
    basic behavior and a model for adding specialized behavior for
    particular characters. But at least initially I'd stick to advertising
    \n in the capabilities.

    This also handles comment splitting: when you insert a line break inside
    a line comment, it will make the new line into an aligned line comment.

    Working on tests, but want people to patch it in and try it - it's hard to
    see if "feel" is right purely by looking at a test.

    Reviewers: ilya-biryukov, hokein

    Subscribers: mgorny, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D60605 (detail/ViewSVN)
    by sammccall
  9. [llvm-readobj/llvm-readelf] - Don't fail to dump the object if .dynsym has broken sh_link field.

    This is https://bugs.llvm.org/show_bug.cgi?id=42215.

    GNU readelf allows to dump the objects in that case,
    but llvm-readobj/llvm-readelf reports an error and stops.

    The patch fixes that.

    Differential revision: https://reviews.llvm.org/D63074 (detail/ViewSVN)
    by grimar
  10. [InstCombine] allow unordered preds when canonicalizing to fabs()

    PR42179:
    https://bugs.llvm.org/show_bug.cgi?id=42179 (detail/ViewSVN)
    by spatel
  11. [InstCombine] add tests for fcmp unordered pred -> fabs (PR42179); NFC (detail/ViewSVN)
    by spatel
  12. [MCA] Fix -Wunused-private-field warning after r362933. NFC

    This should unbreak the buildbots. (detail/ViewSVN)
    by adibiagio
  13. [clangd] Stop marshalling/requiring FormattingOptions. We never did anything with them. (detail/ViewSVN)
    by sammccall
  14. [MCA] Further refactor the bottleneck analysis view. NFCI. (detail/ViewSVN)
    by adibiagio
  15. gn build: Merge r362913 (detail/ViewSVN)
    by nico
  16. [yaml2obj/obj2yaml] - Make RawContentSection::Content and RawContentSection::Size optional

    This is a follow-up for D62809.

    Content and Size fields should be optional as was discussed in comments
    of the D62809's thread. With that, we can describe a specific string table and
    symbol table sections in a more correct way and also show appropriate errors.

    The patch adds lots of test cases where the behavior is described in details.

    Differential revision: https://reviews.llvm.org/D62957 (detail/ViewSVN)
    by grimar
  17. [yaml2obj] - Do not assert when .dynsym is specified explicitly, but .dynstr is not present.

    We have a code in buildSectionIndex() that adds implicit sections:

    // Add special sections after input sections, if necessary.
    for (StringRef Name : implicitSectionNames())
      if (SN2I.addName(Name, SecNo)) {
        // Account for this section, since it wasn't in the Doc
        ++SecNo;
        DotShStrtab.add(Name);
      }

    The problem arises when .dynsym is specified explicitly and no
    DynamicSymbols is used. In that case, we do not add
    .dynstr implicitly and will assert later when will try to set Link
    for .dynsym.

    Seems, in this case, reasonable behavior is to allow Link field to be zero.
    This is what this patch does.

    Differential revision: https://reviews.llvm.org/D63001 (detail/ViewSVN)
    by grimar
  18. [ARM] Enable Unroll UpperBound

    This option allows loops with small max trip counts to be fully unrolled. This
    can help with code like the remainder loops from manually unrolled loops like
    those that appear in the cmsis dsp library. We would apparently previously
    runtime unroll them with the default unroll count (4).

    Differential Revision: https://reviews.llvm.org/D63064 (detail/ViewSVN)
    by dmgreen
  19. Fix MSVC "32-bit shift implicitly converted to 64 bits" warning. NFCI. (detail/ViewSVN)
    by rksimon
  20. [yaml2obj] - Remove helper methods that are probably excessive. NFC.

    These methods are used only once. One of them is not used at all.

    Differential revision: https://reviews.llvm.org/D63002 (detail/ViewSVN)
    by grimar
  21. Revert "Revert "[CodeComplete] Improve overload handling for C++ qualified and ref-qualified methods.""

    This reverts commit r362830, and relands r362785 with the leak fixed. (detail/ViewSVN)
    by sammccall
  22. [DebugInfo] More strict debug range for stack variables

    Variable's stack location can stretch longer than it should. If a
    variable is placed at the stack in a some nested basic block its range
    can be calculated to be up to the next occurrence of the variable's
    DBG_VALUE, or up to the end of the function, thus covering a basic
    blocks that should not be included in the variable’s location range.
    This happens because the DbgEntityHistoryCalculator ends register
    locations at the end of a basic block only if the variable’s location
    register has been changed throughout the function, which is not the
    case for the register used to reference stack objects.

    This patch also tries to produce a single value location if the location
    list builder managed to merge all the locations into one.

    Reviewers: aprantl, dstenb, jmorse

    Reviewed By: aprantl, dstenb, jmorse

    Subscribers: djtodoro, ivanbaev, asowda

    Tags: #debug-info

    Differential Revision: https://reviews.llvm.org/D61600 (detail/ViewSVN)
    by nikolaprica
  23. [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
  24. [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
  25. [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
  26. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

This run spent:

  • 10 hr waiting;
  • 1 hr 20 min build duration;
  • 11 hr total from scheduled to completion.
LLVM/Clang Warnings: 0 warnings.
  • No warnings since build 17,762.
  • Still 70 days before reaching the previous zero warnings highscore.