1. [AMDGPU] Update docs for nontemporal store (details)
  2. [GlobalISel] Add matchers for constant splat. (details)
  3. [lldb] Remove 'extern "C"' from the lldb-swig-python interface (details)
  4. [Analyzer][solver] Do not remove the simplified symbol from the eq class (details)
  5. [Analyzer][Core] Make SValBuilder to better simplify svals with 3 symbols in the tree (details)
  6. [LV] Move code from widenSelectInstruction to VPWidenSelectRecipe. (NFC) (details)
  7. [DebugInfo][InstrRef] "final final" test cleanups for x86 tests (details)
  8. [libc] Add memmove benchmarks (details)
  9. [libc] Add a reasonably optimized version for bcmp (details)
  10. [libc++][ABI BREAK] Do not use the C++03 emulation for std::nullptr_t by default (details)
  11. [DAG] Create fptosi.sat from clamped fptosi (details)
  12. [DebugInfo][InstrRef] Avoid dropping fragment info during PHI elimination (details)
  13. [AMDGPU][NFC] Remove unused defvar in (details)
  14. [DebugInfo][InstrRef][X86] Instrument expanded DYN_ALLOCAs (details)
  15. [mlir] Fix BufferizationToMemRef build. (details)
  16. [mlir] Add bazel build for BufferizationToMemRef. (details)
  17. [DebugInfo][InstrRef] Pre-land on-by-default-for-x86 changes (details)
  18. [fir] Add array value copy pass (details)
  19. [gn build] (semimanually) port 25a7e4b9f7c6 (details)
  20. [lldb] Inline Platform::LoadCachedExecutable into its (single) caller (details)
  21. [lldb] Introduce PlatformQemuUser (details)
Commit 5d602120c3a3c175f606d6ce599cfb60239d904c by jay.foad
[AMDGPU] Update docs for nontemporal store

Update the documented GFX10 code sequence for nontemporal stores after

Differential Revision:
The file was modifiedllvm/docs/AMDGPUUsage.rst
Commit bc5dbb0baee357649c3132254ca6766b5cd6f15b by abinav.puthanpurayil
[GlobalISel] Add matchers for constant splat.

This change exposes isBuildVectorConstantSplat() to the llvm namespace
and uses it to implement the constant splat versions of

CombinerHelper::matchOrShiftToFunnelShift() can now work with vector
types and CombinerHelper::matchMulOBy2()'s match for a constant splat is

Differential Revision:
The file was modifiedllvm/include/llvm/CodeGen/GlobalISel/Utils.h
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/combine-fsh.mir
The file was modifiedllvm/lib/CodeGen/GlobalISel/Utils.cpp
The file was modifiedllvm/include/llvm/CodeGen/GlobalISel/MIPatternMatch.h
The file was modifiedllvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/combine-rot.mir
The file was modifiedllvm/unittests/CodeGen/GlobalISel/PatternMatchTest.cpp
Commit 9a14adeae00015798843ff5cad987e5fdbdddb34 by pavel
[lldb] Remove 'extern "C"' from the lldb-swig-python interface

The LLDBSWIGPython functions had (at least) two problems:
- There wasn't a single source of truth (a header file) for the
  prototypes of these functions. This meant that subtle differences
  in copies of function declarations could go by undetected. And
  not-so-subtle differences would result in strange runtime failures.
- All of the declarations had to have an extern "C" interface, because
  the function definitions were being placed inside and extert "C" block
  generated by swig.

This patch fixes both problems by moving the function definitions to the
%header block of the swig files. This block is not surrounded by extern
"C", and seems more appropriate anyway, as swig docs say it is meant for
"user-defined support code" (whereas the previous %wrapper code was for
automatically-generated wrappers).

It also puts the declarations into the SWIGPythonBridge header file
(which seems to have been created for this purpose), and ensures it is
included by all code wishing to define or use these functions. This
means that any differences in the declaration become a compiler error
instead of a runtime failure.

Differential Revision:
The file was modifiedlldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
The file was modifiedlldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
The file was modifiedlldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
The file was modifiedlldb/bindings/python/python-wrapper.swig
The file was modifiedlldb/bindings/python/python.swig
Commit f02c5f3478318075d1a469203900e452ba651421 by gabor.marton
[Analyzer][solver] Do not remove the simplified symbol from the eq class

Currently, during symbol simplification we remove the original member symbol
from the equivalence class (`ClassMembers` trait). However, we keep the
reverse link (`ClassMap` trait), in order to be able the query the
related constraints even for the old member. This asymmetry can lead to
a problem when we merge equivalence classes:
ClassA: [a, b]   // ClassMembers trait,
a->a, b->a       // ClassMap trait, a is the representative symbol
Now lets delete `a`:
ClassA: [b]
a->a, b->a
Let's merge the trivial class `c` into ClassA:
ClassA: [c, b]
c->c, b->c, a->a
Now after the merge operation, `c` and `a` are actually in different
equivalence classes, which is inconsistent.

One solution to this problem is to simply avoid removing the original
member and this is what this patch does.

Other options I have considered:
1) Always merge the trivial class into the non-trivial class. This might
   work most of the time, however, will fail if we have to merge two
   non-trivial classes (in that case we no longer can track equivalences
2) In `removeMember`, update the reverse link as well. This would cease
   the inconsistency, but we'd loose precision since we could not query
   the constraints for the removed member.

Differential Revision:
The file was modifiedclang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
The file was modifiedclang/test/Analysis/expr-inspection-printState-eq-classes.c
The file was modifiedclang/test/Analysis/symbol-simplification-fixpoint-two-iterations.cpp
The file was modifiedclang/test/Analysis/symbol-simplification-disequality-info.cpp
The file was modifiedclang/test/Analysis/symbol-simplification-fixpoint-one-iteration.cpp
Commit 0a17896fe6fdbbde1f9d3ffbb10a4f3bfa8960f9 by gabor.marton
[Analyzer][Core] Make SValBuilder to better simplify svals with 3 symbols in the tree

Add the capability to simplify more complex constraints where there are 3
symbols in the tree. In this change I extend simplifySVal to query constraints
of children sub-symbols in a symbol tree. (The constraint for the parent is
asked in getKnownValue.)

Differential Revision:
The file was modifiedclang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
The file was modifiedclang/test/Analysis/taint-tester.c
The file was addedclang/test/Analysis/svalbuilder-simplify-compound-svals.cpp
Commit dab776dd0fb43f1c940998cfb64ddfe3cc87ae6f by flo
[LV] Move code from widenSelectInstruction to VPWidenSelectRecipe. (NFC)

The code in widenSelectInstruction has already been transitioned
to only rely on information provided by VPWidenSelectRecipe directly.

Moving the code directly to VPWidenSelectRecipe::execute completes
the transition for the recipe.

It provides the following advantages:

1. Less indirection, easier to see what's going on.
2. Removes accesses to fields of ILV.

2) in particular ensures that no dependencies on
fields in ILV for vector code generation are re-introduced.

Reviewed By: Ayal

Differential Revision:
The file was modifiedllvm/lib/Transforms/Vectorize/LoopVectorize.cpp
Commit a48e05030bbd0d9ac6f49da43b5f34d317b5a520 by jeremy.morse
[DebugInfo][InstrRef] "final final" test cleanups for x86 tests

Two "totally definitely the last ones" instruction referencing test

* fp-stack.ll: this test targets i686, and so it won't be getting
   instruction referencing, or at least not right now,
* X86/live-debug-values.ll: instruction referencing will produce entry
   values in this test, add check lines to account for this. It's not clear
   what the test is supposed to be testing anyway, but the entry values
   appear to be correct.

Differential Revision:
The file was modifiedllvm/test/DebugInfo/X86/live-debug-values.ll
The file was modifiedllvm/test/DebugInfo/COFF/fp-stack.ll
Commit de21f346913cf777436ab0ac0fb707ac04eb3300 by gchatelet
[libc] Add memmove benchmarks

This patch enables the benchmarking of `memmove`.
Ideally, this should be submitted before D114637.

Differential Revision:
The file was modifiedlibc/benchmarks/LibcMemoryBenchmark.cpp
The file was modifiedlibc/benchmarks/LibcMemoryBenchmark.h
The file was modifiedlibc/benchmarks/LibcMemoryBenchmarkMain.cpp
The file was modifiedlibc/benchmarks/LibcDefaultImplementations.cpp
The file was modifiedlibc/benchmarks/LibcFunctionPrototypes.h
The file was modifiedlibc/benchmarks/LibcMemoryGoogleBenchmarkMain.cpp
The file was modifiedlibc/src/string/CMakeLists.txt
The file was modifiedlibc/benchmarks/automemcpy/lib/CodeGen.cpp
The file was modifiedlibc/benchmarks/CMakeLists.txt
Commit af059dfef5a766ceb0ac29318dfb7102131d933e by gchatelet
[libc] Add a reasonably optimized version for bcmp

This is based on current memcmp implementation.

Differential Revision:
The file was addedlibc/src/string/memory_utils/bcmp_implementations.h
The file was modifiedlibc/src/string/memory_utils/CMakeLists.txt
The file was modifiedlibc/src/string/bcmp.cpp
The file was modifiedlibc/src/string/CMakeLists.txt
The file was modifiedlibc/test/src/string/bcmp_test.cpp
Commit a34f24689945e967e4ba4d79ed301d3a71870c7b by Louis Dionne
[libc++][ABI BREAK] Do not use the C++03 emulation for std::nullptr_t by default

We only support Clangs that implement nullptr as an extension in C++03 mode,
and we don't support GCC in C++03 mode. Hence, this patch disables the
use of the std::nullptr_t emulation in C++03 mode by default. Doing that
is technically an ABI break since it changes the mangling for std::nullptr_t.

(1) The only affected users are those compiling in C++03 mode that have
    std::nullptr_t as part of their ABI, which should be reasonably rare.

(2) Those users already have a lingering problem in that their code will
    be incompatible in C++03 and C++11 modes because of that very ABI break.
    Hence, the only users that could really be inconvenienced about this
    change is those that planned on compiling in C++03 mode forever - for
    other users, we're just breaking them now instead of letting them break
    themselves later on when they try to upgrade to C++11.

(3) The ABI break will cause a linker error since the mangling changed,
    and will not result in an obscure runtime error.

Furthermore, if anyone is broken by this, they can define the
_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION macro to return to the
previous behavior. We will then remove that macro after shipping
this for one release if we haven't seen widespread issues.

Concretely, the motivation for making this change is to make our own ABI
consistent in C++03 and C++11 modes and to remove complexity around the
definition of nullptr.

Furthermore, we could investigate making nullptr a keyword in C++03 mode
as a Clang extension -- I don't think that would break anyone, since
libc++ already defines nullptr as a macro to something else. Only users
that do not use libc++ and compile in C++03 mode could potentially be
broken by that.

Differential Revision:
The file was modifiedlibcxx/docs/ReleaseNotes.rst
The file was modifiedlibcxx/include/__config
Commit 52ff3b009388f1bef4854f1b6470b4ec19d10b0e by
[DAG] Create fptosi.sat from clamped fptosi

This adds a fold in DAGCombine to create fptosi_sat from sequences for
smin(smax(fptosi(x))) nodes, where the min/max saturate the output of
the fp convert to a specific bitwidth (say INT_MIN and INT_MAX). Because
it is dealing with smin(/smax) in DAG they may currently be ISD::SMIN,
to be handled similarly.

A shouldConvertFpToSat method was added to control when converting may
be profitable. The original fptosi will have a less strict semantics
than the fptosisat, with less values that need to produce defined

This especially helps on ARM/AArch64 where the vcvt instructions
naturally saturate the result.

Differential Revision:
The file was modifiedllvm/lib/Target/AArch64/AArch64ISelLowering.h
The file was modifiedllvm/lib/Target/RISCV/RISCVISelLowering.cpp
The file was modifiedllvm/test/CodeGen/AArch64/fpclamptosat.ll
The file was modifiedllvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
The file was modifiedllvm/lib/Target/AArch64/AArch64ISelLowering.cpp
The file was modifiedllvm/lib/Target/ARM/ARMISelLowering.h
The file was modifiedllvm/test/CodeGen/Thumb2/mve-fpclamptosat_vec.ll
The file was modifiedllvm/include/llvm/CodeGen/TargetLowering.h
The file was modifiedllvm/lib/Target/ARM/ARMISelLowering.cpp
The file was modifiedllvm/test/CodeGen/WebAssembly/fpclamptosat_vec.ll
The file was modifiedllvm/lib/Target/RISCV/RISCVISelLowering.h
The file was modifiedllvm/test/CodeGen/AArch64/fpclamptosat_vec.ll
The file was modifiedllvm/test/CodeGen/RISCV/fpclamptosat.ll
The file was modifiedllvm/test/CodeGen/ARM/fpclamptosat.ll
The file was modifiedllvm/test/CodeGen/X86/fpclamptosat.ll
The file was modifiedllvm/test/CodeGen/WebAssembly/fpclamptosat.ll
Commit 8dda516b83255f96b3918f73bb64282655c4cc75 by jeremy.morse
[DebugInfo][InstrRef] Avoid dropping fragment info during PHI elimination

InstrRefBasedLDV used to crash on the added test -- the exit block is not
in scope for the variable being propagated, but is still considered because
it contains an assignment. The failure-mode was vlocJoin ignoring
assign-only blocks and not updating DIExpressions, but pickVPHILoc would
still find a variable location for it. That led to DBG_VALUEs created with
the wrong fragment information.

Fix this by removing a filter inherited from VarLocBasedLDV: vlocJoin will
now consider assign-only blocks and will update their expressions.

Differential Revision:
The file was modifiedllvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
The file was addedllvm/test/DebugInfo/MIR/InstrRef/out-of-scope-blocks.mir
The file was modifiedllvm/unittests/CodeGen/InstrRefLDVTest.cpp
The file was modifiedllvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h
Commit 14c4051122bf4070d624b82189f1093758ecdf69 by abinav.puthanpurayil
[AMDGPU][NFC] Remove unused defvar in
The file was modifiedllvm/lib/Target/AMDGPU/
Commit 7093c8101033cc104ce79e8871ac0fb9b70b28c3 by jeremy.morse
[DebugInfo][InstrRef][X86] Instrument expanded DYN_ALLOCAs

If we have a DYN_ALLOCA_* instruction, it will eventually be expanded to a
stack probe and subtract-from-SP. Add debug-info instrumentation to
X86FrameLowering::emitStackProbe so that it can redirect debug-info for the
DYN_ALLOCA to the lowered stack probe. In practice, this means putting an
instruction number label either the call instruction to _chkstk for win32,
or more commonly on the subtract from SP instruction. The two tests added
cover both of these cases.

Differential Revision:
The file was modifiedllvm/lib/Target/X86/X86DynAllocaExpander.cpp
The file was addedllvm/test/DebugInfo/X86/instr-ref-dyn-alloca-win32.ll
The file was modifiedllvm/lib/Target/X86/X86FrameLowering.cpp
The file was addedllvm/test/DebugInfo/X86/instr-ref-dyn-alloca.ll
The file was modifiedllvm/lib/Target/X86/X86FrameLowering.h
Commit f910aa910555b563f552b2abfc172a2f97a5fb34 by pifon
[mlir] Fix BufferizationToMemRef build.
The file was modifiedmlir/lib/Conversion/BufferizationToMemRef/CMakeLists.txt
The file was modifiedutils/bazel/llvm-project-overlay/mlir/BUILD.bazel
Commit 97db64082eb02f831e51b311bd9b7c39e0817e23 by pifon
[mlir] Add bazel build for BufferizationToMemRef.
The file was modifiedutils/bazel/llvm-project-overlay/mlir/BUILD.bazel
Commit 651122fc4ac92b93f36aab3b194de21065a0c48e by jeremy.morse
[DebugInfo][InstrRef] Pre-land on-by-default-for-x86 changes

Over in D114631 and [0] there's a plan for turning instruction referencing
on by default for x86. This patch adds / removes all the relevant bits of
code, with the aim that the final patch is extremely small, for an easy
revert. It should just be a condition in CommandFlags.cpp and removing the
XFail on instr-ref-flag.ll.

The file was modifiedllvm/include/llvm/CodeGen/CommandFlags.h
The file was modifiedllvm/lib/CodeGen/CommandFlags.cpp
The file was removedclang/test/Driver/debug-var-experimental-switch.c
The file was modifiedclang/include/clang/Driver/
The file was addedllvm/test/DebugInfo/X86/instr-ref-flag.ll
Commit 47f759309eeaf9bd77debe4f6c3e1fe52913b537 by clementval
[fir] Add array value copy pass

This patch upstream the array value copy pass.

Transform the set of array value primitives to a memory-based array

The Ops `array_load`, `array_store`, `array_fetch`, and `array_update` are
used to manage abstract aggregate array values. A simple analysis is done
to determine if there are potential dependences between these operations.
If not, these array operations can be lowered to work directly on the memory
representation. If there is a potential conflict, a temporary is created
along with appropriate copy-in/copy-out operations. Here, a more refined
analysis might be deployed, such as using the affine framework.

This pass is required before code gen to the LLVM IR dialect.

This patch is part of the upstreaming effort from fir-dev branch. The
pass is bringing quite a lot of file with it.

Reviewed By: kiranchandramohan, schweitz

Differential Revision:

Co-authored-by: Jean Perier <>
Co-authored-by: Eric Schweitz <>
Co-authored-by: V Donaldson <>
The file was modifiedflang/include/flang/Optimizer/Builder/FIRBuilder.h
The file was modifiedflang/lib/Optimizer/Builder/FIRBuilder.cpp
The file was modifiedflang/lib/Optimizer/Transforms/CMakeLists.txt
The file was addedflang/lib/Optimizer/Transforms/ArrayValueCopy.cpp
The file was modifiedflang/include/flang/Optimizer/Dialect/FIROpsSupport.h
The file was modifiedflang/test/Fir/invalid.fir
The file was modifiedflang/include/flang/Optimizer/Builder/Runtime/RTBuilder.h
The file was modifiedflang/include/flang/Optimizer/Dialect/
The file was modifiedflang/lib/Optimizer/Dialect/FIROps.cpp
The file was modifiedflang/include/flang/Optimizer/Transforms/Passes.h
The file was addedflang/include/flang/Optimizer/Transforms/Factory.h
The file was addedflang/test/Fir/array-value-copy.fir
The file was modifiedflang/include/flang/Optimizer/Transforms/
The file was modifiedflang/unittests/Optimizer/Builder/FIRBuilderTest.cpp
Commit ee0c75eba31bdaf32e8f01803408d63ae42e3339 by thakis
[gn build] (semimanually) port 25a7e4b9f7c6
The file was modifiedllvm/utils/gn/secondary/compiler-rt/lib/sanitizer_common/
Commit a6e673643c44f94557fa09022a3c6edf76167871 by pavel
[lldb] Inline Platform::LoadCachedExecutable into its (single) caller
The file was modifiedlldb/source/Target/Platform.cpp
The file was modifiedlldb/include/lldb/Target/Platform.h
Commit 1408684957bbfb5b412e0ef3c027c88daa1058eb by pavel
[lldb] Introduce PlatformQemuUser

This adds a new platform class, whose job is to enable running
(debugging) executables under qemu.

(For general information about qemu, I recommend reading the RFC thread
on lldb-dev

This initial patch implements the necessary boilerplate as well as the
minimal amount of functionality needed to actually be able to do
something useful (which, in this case means debugging a fully statically
linked executable).

The knobs necessary to emulate dynamically linked programs, as well as
to control other aspects of qemu operation (the emulated cpu, for
instance) will be added in subsequent patches. Same goes for the ability
to automatically bind to the executables of the emulated architecture.

Currently only two settings are available:
- architecture: the architecture that we should emulate
- emulator-path: the path to the emulator

Even though this patch is relatively small, it doesn't lack subtleties
that are worth calling out explicitly:
- named sockets: qemu supports tcp and unix socket connections, both of
  them in the "forward connect" mode (qemu listening, lldb connecting).
  Forward TCP connections are impossible to realise in a race-free way.
  This is the reason why I chose unix sockets as they have larger, more
  structured names, which can guarantee that there are no collisions
  between concurrent connection attempts.
- the above means that this code will not work on windows. I don't think
  that's an issue since user mode qemu does not support windows anyway.
- Right now, I am leaving the code enabled for windows, but maybe it
  would be better to disable it (otoh, disabling it means windows
  developers can't check they don't break it)
- qemu-user also does not support macOS, so one could contemplate
  disabling it there too. However, macOS does support named sockets, so
  one can even run the (mock) qemu tests there, and I think it'd be a
  shame to lose that.

Differential Revision:
The file was addedlldb/source/Plugins/Platform/QemuUser/
The file was addedlldb/test/API/qemu/Makefile
The file was modifiedlldb/source/Plugins/Platform/CMakeLists.txt
The file was addedlldb/test/API/qemu/
The file was addedlldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.h
The file was addedlldb/test/API/qemu/main.c
The file was addedlldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
The file was addedlldb/test/API/qemu/
The file was modifiedlldb/packages/Python/lldbsuite/test/
The file was addedlldb/source/Plugins/Platform/QemuUser/CMakeLists.txt