1. Dec 07, 2021
    • Jonas Paulsson's avatar
      [SystemZ] Improve codegen for memset. · cbf682cb
      Jonas Paulsson authored
      Memset with a constant length was implemented with a single store followed by
      a series of MVC:s. This patch changes this so that one store of the byte is
      emitted for each MVC, which avoids data dependencies between the MVCs. An
      MVI/STC + MVC(len-1) is done for each block.
      
      In addition, memset with a variable length is now also handled without a
      libcall. Since the byte is first stored and then MVC is used from that
      address, a length of two must now be subtracted instead of one for the loop
      and EXRL. This requires an extra check for the one-byte case, which is
      handled in a special block with just a single MVI/STC (like GCC).
      
      Review: Ulrich Weigand
      
      Differential Revision: https://reviews.llvm.org/D112004
      cbf682cb
    • Martin Probst's avatar
      clang-format: [JS] test case for numeric separators. · 327d9663
      Martin Probst authored
      ES2021 allows numeric literals using `_` as a separator. This already
      works, but had no test.
      
      Differential Revision: https://reviews.llvm.org/D115147
      327d9663
    • Noah Shutty's avatar
      [llvm] [Debuginfo] Debuginfod client library. · 4a16fe13
      Noah Shutty authored
      This adds a Debuginfod client library which queries servers specified by the `DEBUGINFOD_URLS` environment variable for the debuginfo, executable, or a specified source file associated with a given build id.
      
      Reviewed By: dblaikie
      
      Differential Revision: https://reviews.llvm.org/D112758
      4a16fe13
    • Aaron Ballman's avatar
      Introduce _BitInt, deprecate _ExtInt · 6c75ab5f
      Aaron Ballman authored
      WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
      type to be _BitInt. This patch does the vast majority of the work to
      rename _ExtInt to _BitInt, which accounts for most of its size. The new
      type is exposed in older C modes and all C++ modes as a conforming
      extension. However, there are functional changes worth calling out:
      
      * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
      * Updates the mangling for the type.
      * Updates the documentation and adds a release note to warn users what
      is going on.
      * Adds new diagnostics for use of _BitInt to call out when it's used as
      a Clang extension or as a pre-C23 compatibility concern.
      * Adds new tests for the new diagnostic behaviors.
      
      I want to call out the ABI break specifically. We do not believe that
      this break will cause a significant imposition for early adopters of
      the feature, and so this is being done as a full break. If it turns out
      there are critical uses where recompilation is not an o...
      6c75ab5f
    • Balazs Benics's avatar
      [analyzer][solver] Fix assertion on (NonLoc, Op, Loc) expressions · a6816b95
      Balazs Benics authored
      Previously, the `SValBuilder` could not encounter expressions of the
      following kind:
      
        NonLoc OP Loc
        Loc OP NonLoc
      
      Where the `Op` is other than `BO_Add`.
      
      As of now, due to the smarter simplification and the fixedpoint
      iteration, it turns out we can.
      It can happen if the `Loc` was perfectly constrained to a concrete
      value (`nonloc::ConcreteInt`), thus the simplifier can do
      constant-folding in these cases as well.
      
      Unfortunately, this could cause assertion failures, since we assumed
      that the operator must be `BO_Add`, causing a crash.
      
      ---
      
      In the patch, I decided to preserve the original behavior (aka. swap the
      operands (if the operator is commutative), but if the `RHS` was a
      `loc::ConcreteInt` call `evalBinOpNN()`.
      
      I think this interpretation of the arithmetic expression is closer to
      reality.
      
      I also tried naively introducing a separate handler for
      `loc::ConcreteInt` RHS, before doing handling the more generic `Loc` RHS
      case. However, it broke the `zoo1backwards()` test in the `nullptr.cpp`
      file. This highlighted for me the importance to preserve the original
      behavior for the `BO_Add` at least.
      
      PS: Sorry for introducing yet another branch into this `evalBinOpXX`
      madness. I've got a couple of ideas about refactoring these.
      We'll see if I can get to it.
      
      The test file demonstrates the issue and makes sure nothing similar
      happens. The `no-crash` annotated lines show, where we crashed before
      applying this patch.
      
      Reviewed By: martong
      
      Differential Revision: https://reviews.llvm.org/D115149
      a6816b95
    • James Farrell's avatar
      Revert "Use VersionTuple for parsing versions in Triple, fixing issues that... · 63a6348c
      James Farrell authored
      Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible."
      
      This reverts commit 50324670.
      63a6348c
    • Jonas Devlieghere's avatar
      Revert "[clang][DebugInfo] Allow function-local statics and types to be scoped... · 4cb79294
      Jonas Devlieghere authored
      Revert "[clang][DebugInfo] Allow function-local statics and types to be scoped within a lexical block"
      
      This reverts commit e403f4fd because it
      breaks TestSetData.py on GreenDragon:
      
      https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/39089/
      4cb79294
    • Craig Topper's avatar
      [RISCV] Loosen some restrictions on lowering constant BUILD_VECTORs using vid.v. · acdbd34c
      Craig Topper authored
      The immediate size check on StepNumerator did not take into account
      that vmul.vi does not exist. It also did not account for power of 2
      constants that can be done with vshl.vi.
      
      This patch fixes this by moving the conversion from mul to shift
      further up. Then we can consider the immediates separately for MUL
      vs SHL. For MUL I've allowed simm12 which requires a single addi
      before a vmul.vx. For SHL I've allowed any uimm5 which works with
      vshl.vi. We could relax these further in the future. This is a
      starting point that allows us to emit the same number of instructions
      we were already using for smaller numerators.
      
      Reviewed By: frasercrmck
      
      Differential Revision: https://reviews.llvm.org/D115081
      acdbd34c
    • Joseph Huber's avatar
      [OpenMP] Make reduction functions SPMD compatible · 744aa09f
      Joseph Huber authored
      Reduction functions were guarded before which was wrong, these are SPMD
      compatible.
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D115159
      744aa09f
    • Joseph Huber's avatar
      [OpenMP][FIX] Invalidate the SPMDCompatibilityTracker explicitly · 9ea5b972
      Joseph Huber authored
      Before SPMDzation it was sufficient to add an incompatible instruction
      to the SPMDCompatibilityTracker. However, now adding instructions means
      they need guarding. As calls cannot be guarded in general we need to
      explicitly prevent SPMD mode.
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D115158
      9ea5b972
    • Evgeny Mandrikov's avatar
      Fix compilation of Google Test in C++20 mode · c94eb0f9
      Evgeny Mandrikov authored
      Without this patch when using CMAKE_CXX_STANDARD=20
      and MSVC 19.30.30705.0 compilation of unit tests
      fails with
      
      llvm\utils\unittest\googlemock\include\gmock/gmock-actions.h(828): error C2039: 'result_of': is not a member of 'std'
      
      Patch is taken from Google Test:
      https://github.com/google/googletest/commit/61f010d703b32de9bfb20ab90ece38ab2f25977f
      
      Do not use std::result_of as it was removed in C++20.
      
      Differential Revision: https://reviews.llvm.org/D115163
      c94eb0f9
    • LLVM GN Syncbot's avatar
      [gn build] Port c68f71eb · 73195657
      LLVM GN Syncbot authored
      73195657
    • spupyrev's avatar
      ext-tsp basic block layout · c68f71eb
      spupyrev authored
      A new basic block ordering improving existing MachineBlockPlacement.
      
      The algorithm tries to find a layout of nodes (basic blocks) of a given CFG
      optimizing jump locality and thus processor I-cache utilization. This is
      achieved via increasing the number of fall-through jumps and co-locating
      frequently executed nodes together. The name follows the underlying
      optimization problem, Extended-TSP, which is a generalization of classical
      (maximum) Traveling Salesmen Problem.
      
      The algorithm is a greedy heuristic that works with chains (ordered lists)
      of basic blocks. Initially all chains are isolated basic blocks. On every
      iteration, we pick a pair of chains whose merging yields the biggest increase
      in the ExtTSP value, which models how i-cache "friendly" a specific chain is.
      A pair of chains giving the maximum gain is merged into a new chain. The
      procedure stops when there is only one chain left, or when merging does not
      increase ExtTSP. In the latter case, the remaining chains are sorted by
      density in decreasing order.
      
      An important aspect is the way two chains are merged. Unlike earlier
      algorithms (e.g., based on the approach of Pettis-Hansen), two
      chains, X and Y, are first split into three, X1, X2, and Y. Then we
      consider all possible ways of gluing the three chains (e.g., X1YX2, X1X2Y,
      X2X1Y, X2YX1, YX1X2, YX2X1) and choose the one producing the largest score.
      This improves the quality of the final result (the search space is larger)
      while keeping the implementation sufficiently fast.
      
      Differential Revision: https://reviews.llvm.org/D113424
      c68f71eb
    • Jon Chesterfield's avatar
      [openmp] Default to new rtl for amdgpu · 6bb2a4f3
      Jon Chesterfield authored
      Reverts D114965 as the compiler backend appears to be working again
      
      Reviewed By: jhuber6
      
      Differential Revision: https://reviews.llvm.org/D115157
      6bb2a4f3
    • Peter Waller's avatar
      [AArch64][SVE] Fix ICE extracting fixedvec from scalable load · a6f751c3
      Peter Waller authored
      f526c600 had a concern raised because of an invalid typesize request
      on a scalable vector, which this patch addresses.
      
      Prevent shouldReduceLoadWidth from attempting to query the bit size, and
      add a regression test in sve-extract-fixed-vector.ll.
      
      Differential Revision: https://reviews.llvm.org/D115156
      a6f751c3
    • Kazu Hirata's avatar
      [CodeGen] Use range-based for loops (NFC) · c4a8928b
      Kazu Hirata authored
      c4a8928b
    • Jon Chesterfield's avatar
      [libomptarget] Add cmake variables to disable building the amdgpu or cuda plugins · a05a0c3c
      Jon Chesterfield authored
      Analogous to the controls on building device runtimes
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D115148
      a05a0c3c
    • Jon Chesterfield's avatar
      [openmp] Run tests on both runtimes, independent of the default · a2b3b4da
      Jon Chesterfield authored
      Minor fix to the lit.cfg. Currently, nvptx runs the tests twice on the new runtime.
      Soon, amdgpu will run them on the new runtime as well as the old.
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D115150
      a2b3b4da
    • Bardia Mahjour's avatar
      [VP] getVPMemoryOpCost interface · dfcfd140
      Bardia Mahjour authored
      Added TTI queries for the cost of a VP Memory operation, and added Opcode,
      DataType and Alignment to the hasActiveVectorLength() interface.
      
      Reviewed By: Roland Froese
      
      Differential Revision: https://reviews.llvm.org/D109416
      dfcfd140
    • Arthur O'Dwyer's avatar
      [libc++] Work around a Clang bug in transform_view, and regression-test. · dcdb07ab
      Arthur O'Dwyer authored
      Clang trunk rejects the new test case, but this is a Clang bug
      (PR47414, 47509, 50864, 44833).
      
      ```
      In module 'std' imported from /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:17:
      /Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:85:44: error: constraints not satisfied for alias template 'range_reference_t' [with _Rp = const NonConstView]
                   regular_invocable<const _Fn&, range_reference_t<const _View>>
                                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:416:25: note: in instantiation of template class 'std::ranges::transform_view<NonConstView, (lambda at /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:73:71)>' requested here
            -> decltype(      transform_view(_VSTD::forward<_Range>(__range), _VSTD::forward<_Fn>(__f)))
                              ^
      ```
      
      We can work around this by adding a layer of indirection: put the
      problematic constraint into a named concept and Clang becomes more
      amenable to SFINAE'ing instead of hard-erroring.
      
      Drive-by simplify `range.transform/general.pass.cpp` to make it clearer
      what it's actually testing in this area.
      
      Differential Revision: https://reviews.llvm.org/D115116
      dcdb07ab
  2. Dec 06, 2021