Started 1 yr 11 mo ago
Took 1 hr 10 min on green-dragon-23

Success Build #2974 (Aug 9, 2019 5:00:27 AM)

Build Artifacts
test_logs.tgz49.13 KB view
  • : 368432
  • : 368413
  • : 368425
  • : 364589
  • : 368317
  1. [MCA] Add flag -show-encoding to llvm-mca.

    Flag -show-encoding enables the printing of instruction encodings as part of the
    the instruction info view.

    Example (with flags -mtriple=x86_64--  -mcpu=btver2):

    Instruction Info:
    [1]: #uOps
    [2]: Latency
    [3]: RThroughput
    [4]: MayLoad
    [5]: MayStore
    [6]: HasSideEffects (U)
    [7]: Encoding Size

    [1]    [2]    [3]    [4]    [5]    [6]    [7]    Encodings:     Instructions:
    1      2     1.00                         4     c5 f0 59 d0    vmulps   %xmm0, %xmm1, %xmm2
    1      4     1.00                         4     c5 eb 7c da    vhaddps  %xmm2, %xmm2, %xmm3
    1      4     1.00                         4     c5 e3 7c e3    vhaddps  %xmm3, %xmm3, %xmm4

    In this example, column Encoding Size is the size in bytes of the instruction
    encoding. Column Encodings reports the actual instruction encodings as byte
    sequences in hex (objdump style).

    The computation of encodings is done by a utility class named mca::CodeEmitter.

    In future, I plan to expose the CodeEmitter to the instruction builder, so that
    information about instruction encoding sizes can be used by the simulator. That
    would be a first step towards simulating the throughput from the decoders in the
    hardware frontend.

    Differential Revision: (detail)
    by adibiagio
  2. [AArch64] Set pref. func. align to 8 bytes on Neoverse E1 & Cortex-A65

    The Arm Neoverse E1 and Cortex-A65 Software Optimization Guide [1][2],
    Section "4.7 Branch instruction alignment" state:

    "It is preferable for branch targets, including subroutine entry points,
    to be placed on aligned 64-bit boundaries to maximize instruction fetch

    This patch sets the preferred function alignment on Neoverse E1 and
    Cortex-A65 to 2^3=8B. This was already the case in some Cortex-A CPUs
    such as Cortex-A53.


    Reviewers: dmgreen, fhahn, samparker

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

    Tags: #llvm

    Differential Revision: (detail)
    by pabbar01
  3. [llvm-readobj] - Remove `error(llvm::Expected<T> &&E)`

    This is a bit strange method. It works like a unwrapOrError,
    but named error. It does not report an Input name.
    I removed it.

    Differential revision: (detail)
    by grimar
  4. [llvm-readobj] - Remove deprecated unwrapOrError(Expected<T> EO).

    This patch changes the code to use a modern unwrapOrError(StringRef Input, Expected<T> EO)
    version that contains the input source name and removes the deprecated version.

    Differential revision: (detail)
    by grimar
  5. [lldb][NFC] Unify InstrList typedef in IRForTarget (detail)
    by teemperor
  6. [lldb][NFC] Fix warning about missing switch cases

    These types were recently added in D62960 but it seems the patch didn't
    consider LLDB which causes a bunch of compiler warnings about
    missing enum values. It seems this feature isn't fully implemented yet,
    so I don't think we can write any test for this. For now lets just add
    the missing types to our usual list of unsupported types. (detail)
    by teemperor
  7. AArch64: support TLS on Darwin platforms in GlobalISel.

    All TLS access on Darwin is in the "general dynamic" form where we call
    a function to resolve the address, so implementation is pretty simple. (detail)
    by tnorthover
  8. [lldb] Refactor guard variable checks in IRForTarget

    Not NFC as this will probably fix a wrong guard variable check
    on Windows. Not sure though what Windows test can now be safely
    enabled. (detail)
    by teemperor
  9. Minidump/Windows: Fix module lookup

    When opening a minidump, we were failing to find an executable because
    we were searching for i386-unknown-windows, whereas we recognize the
    pe/coff files as i386-pc-windows. This fixes the triple computation code
    in the minidump parser to match pe/coff, and adds an appropriate test.

    NB: I'm not sure setting the vendor to "pc" is really correct for
    arm(64) windows, but right now that seems to match what we do in the
    pe/coff case (ArchSpec.cpp:935).

    Reviewers: clayborg, amccarth

    Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits

    Differential Revision: (detail)
    by labath
  10. [lldb][NFC] Clean up logging in IRForTarget (detail)
    by teemperor
  11. Add SVE opaque built-in types

    This patch adds the SVE built-in types defined by the Procedure Call
    Standard for the Arm Architecture:

    It handles the types in all relevant places that deal with built-in types.
    At the moment, some of these places bail out with an error, including:

       (1) trying to generate LLVM IR for the types
       (2) trying to generate debug info for the types
       (3) trying to mangle the types using the Microsoft C++ ABI
       (4) trying to @encode the types in Objective C

    (1) and (2) are fixed by follow-on patches but (unlike this patch)
    they deal mostly with target-specific LLVM details, so seemed like
    a logically separate change.  There is currently no spec for (3) and
    (4), so reporting an error seems like the correct behaviour for now.

    The intention is that the types will become sizeless types:

    The main purpose of the sizeless type extension is to diagnose
    impossible or dangerous uses of the types, such as any that would
    require sizeof to have a meaningful defined value.

    Until then, the patch sets the alignments of the types to the values
    specified in the link above.  It also sets the sizes of the types to
    zero, which is chosen to be consistently wrong and shouldn't affect
    correctly-written code (i.e. code that would compile even with the
    sizeless type extension).

    The patch adds the common subset of functionality needed to test the
    sizeless type extension on the one hand and to provide SVE intrinsic
    functions on the other.  After this patch, the two pieces of work are
    essentially independent.

    The patch is based on one by Graham Hunter:

    Differential Revision: (detail)
    by rsandifo
  12. [llvm-readobj] - Remove unwrapOrError(ErrorOr<T> EO) helper.

    It is outdated. Using of Expected<> is preferred, also it does
    not provide a way to report a file name.

    I updated the code to use the modern version of unwrapOrError instead.

    Differential revision: (detail)
    by grimar
  13. GlobalISel: pack various parameters for lowerCall into a struct.

    I've now needed to add an extra parameter to this call twice recently. Not only
    is the signature getting extremely unwieldy, but just updating all of the
    callsites and implementations is a pain. Putting the parameters in a struct
    sidesteps both issues. (detail)
    by tnorthover
  14. [lldb][NFC] Remove last C string uses from IRForTarget (detail)
    by teemperor
  15. [lldb][NFC] Use range-based for-loops in IRForTarget (detail)
    by teemperor
  16. [ARM][ParallelDSP] Replace SExt uses

    As loads are combined and widened, we replaced their sext users
    operands whereas we should have been replacing the uses of the sext.
    I've added a load of tests, with only a few of them originally
    causing assertion failures, the rest improve pattern coverage.

    Differential Revision: (detail)
    by sam_parker
  17. [AST] No longer visiting CXXMethodDecl bodies created by compiler when method was default created.

    Clang generates function bodies and puts them in the AST for default methods if it is defaulted outside the class definition.

    struct A {
       A &operator=(A &&O);

    A &A::operator=(A &&O) = default;

    This will generate a function body for the `A &A::operator=(A &&O)` and put it in the AST. This body should not be visited if implicit code is not visited as it is implicit.

    This was causing SemanticHighlighting in clangd to generate duplicate tokens and putting them in weird places.

    Reviewers: hokein, ilya-biryukov, gribozavr

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

    Tags: #clang

    Differential Revision: (detail)
    by jvikstrom
  18. [InstSimplify] Report "Changed" also when only deleting dead instructions

    Make sure that we report that changes has been made
    by InstSimplify also in situations when only trivially
    dead instructions has been removed. If for example a call
    is removed the call graph must be updated.

    Bug seem to have been introduced by llvm-svn r367173
    (commit 02b9e45a7e4b81), since the code in question
    was rewritten in that commit.

    Reviewers: spatel, chandlerc, foad

    Reviewed By: spatel

    Subscribers: hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by bjope
  19. [X86] Remove code that expands truncating stores from combineStore.

    We shouldn't form trunc stores that need to be expanded now that
    we are using widening legalization. (detail)
    by ctopper
  20. Use ASSERT_THAT_ERROR instead of logAllUnhandledErrors/exit

    Summary: ASSERT_THAT_ERROR looks like the intended helper for use in tests.

    Reviewers: plotfi, jkorous, compnerd

    Subscribers: mgorny, dexonsmith, cfe-commits

    Tags: #clang

    Differential Revision: (detail)
    by gribozavr
  21. Fix rpath for MacOS/iOS

    Summary: libs can be installed to ../lib64.

    Subscribers: mgorny, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by hhb
  22. [X86] Remove stale FIXME from combineMaskedStore. NFC

    I believe PR34584 was tracking that FIXME, but its since been
    closed and a test case was added. (detail)
    by ctopper
  23. [X86] Remove DAG combine expansion of extending masked load and truncating masked store.

    The only way to generate these was through promoting legalization
    of narrow vectors, but we widen those types now. So we shouldn't
    produce these nodes. (detail)
    by ctopper

Started by upstream project LLDB Incremental build number 96
originally caused by:

Started by upstream project LLDB Incremental build number 97
originally caused by:

Started by upstream project LLDB Incremental build number 98
originally caused by:

Started by upstream project LLDB Incremental build number 99
originally caused by:

Started by upstream project LLDB Incremental build number 100
originally caused by:

Started by upstream project LLDB Incremental build number 101
originally caused by:

Started by upstream project LLDB Incremental build number 102
originally caused by:

Started by upstream project LLDB Incremental build number 105
originally caused by:

Started by upstream project LLDB Incremental build number 106
originally caused by:

Started by upstream project LLDB Incremental build number 107
originally caused by:

Started by upstream project LLDB Incremental build number 108
originally caused by:

Started by upstream project LLDB Incremental build number 109
originally caused by:

This run spent:

  • 5 hr 56 min waiting;
  • 1 hr 10 min build duration;
  • 7 hr 6 min total from scheduled to completion.
Test Result (no failures)