[libc] Add LIBC_INLINE_VAR for inline variables

These are the only variables I could find that use LIBC_INLINE. Note, these are namespace scoped constexpr so local linkage is implied. inline is useful here to silence clang's unused-const-variable variable. For Fuchsia, the distinction between LIBC_INLINE and LIBC_INLINE_VAR is helpful because we define LIBC_INLINE as `[[gnu::always_inline]] inline` when building with gcc. This isn't meaningful on variables.

Alternatively, we could make these variables simply constexpr and also add `[[maybe_unused]]`

Reviewed By: sivachandra, mcgrathr

Differential Revision: https://reviews.llvm.org/D152951

[Clang] Fixes a diagnostic typo.

Some small style updates as drive-by.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D153038

[libc++][doc] Move not yet adopted issues to C++26.

The development of C++23 is complete, so these issues will be adopted in
C++26 (or later).

Reviewed By: #libc, philnik

Differential Revision: https://reviews.llvm.org/D153053

[NFC] Autogenerate CodeGen/ARM/vlddup.ll

[Driver] Allow warning for unclaimed TargetSpecific options

For unclaimed target-agnostic options, we can apply clang_ignored_gcc_optimization_f_Group
to accept but warn about them.
```
% clang -c -fexpensive-optimizations a.c
clang: warning: optimization flag '-fexpensive-optimizations' is not supported [-Wignored-optimization-argument]
```

For an unclaimed target-specific option, one target may want to accept but warn
about it. Add `llvm::opt::Arg::IgnoredTargetSpecific` to support this warning
need.

Close https://github.com/llvm/llvm-project/issues/63282

Reviewed By: mstorsjo

Differential Revision: https://reviews.llvm.org/D152856

[NFC] Autogenerate CodeGen/ARM/sub-cmp-peephole.ll

[LV] Use VPValues when creating GEP with all invariant indices.

Update VPWidenGEPRecipe::execute to use the VPValue operands of the
recipe when creating the GEP instruction.

Fixes #63340.

[gn build] Port 31eeba3f7c0e

[libc++] Introduce __make_uninitialized_buffer and use it instead of get_temporary_buffer

This will also be used in some PSTL backends.

Reviewed By: ldionne, #libc, Mordante

Spies: arichardson, mstorsjo, Mordante, sstefan1, jplehr, libcxx-commits

Differential Revision: https://reviews.llvm.org/D152208

[mlir] Move symbol loading from mlir-cpu-runner to ExecutionEngine.

Both the mlir-cpu-runner and the execution engine allow to provide a
list of shared libraries that should be loaded into the process such
that the jitted code can use the symbols from those libraries. The
runner had implemented a protocol that allowed libraries to control
which symbols it wants to provide in that context (with a function
called __mlir_runner_init). In absence of that, the runner would rely on
the loading mechanism of the execution engine, which didn't do anything
particular with the symbols, i.e., only symbols with public visibility
were visible to jitted code.

Libraries used a mix of the two mechanisms: while the runner utils and C
runner utils libs (and potentially others) used public visibility, the
async runtime lib (as the only one in the monorepo) used the loading
protocol. As a consequence, the async runtime library could not be used
through the Python bindings of the execution engine.

This patch moves the loading protocol from the runner to the execution
engine. For the runner, this should not change anything: it lets the
execution engine handle the loading which now implements the same
protocol that the runner had implemented before. However, the Python
binding now get to benefit from the loading protocol as well, so the
async runtime library (and potentially other out-of-tree libraries) can
now be used in that context.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D153029

[Driver] Use DenseSet::contains (NFC)

[BOLT] Use {StringMap,DenseMapBase}::lookup (NFC)

[AMDGPU] Regenerate llvm.amdgcn.s.buffer.load checks

[GlobalISel][X86] Add handling of scalar G_UADDO/G_USUBO opcodes

This finally allows x86 globalisel to lower addition/subtraction of illegal types without fallback :)

Revert "[lit] Avoid os.path.realpath in lit.py due to MAX_PATH limitations on Windows"

This reverts commit c1cf459cbd79cc7d6ca834390649fb9185a4b237.

Reverting to permit time to explore the underlying issue.  This change
regressed the clang-PPC64-AIX and m68k-linux-cross builders.

Differential Revision: https://reviews.llvm.org/D153138
Reviewed By: compnerd

[clang][Interp] Handle PredefinedExprs

Differential Revision: https://reviews.llvm.org/D148689

[CGP] Fix infinite loop in icmp operand swapping

Don't swap the operands if they're the same. Fixes the issue reported
at https://reviews.llvm.org/D152541#4427017.

[libc++][NFC] Consistently qualify malloc and free calls with std::

[libc++] Make libc++ and libc++abi's definitions of operator new be exact copies

This allows mechanically copying any changes made to `operator new`
from libc++ into libc++abi as-is. This is also a step towards
de-duplicating this code entirely.

Differential Revision: https://reviews.llvm.org/D153035

[clang][Interp] Check inc/dec family of ops for initialization

Differential Revision: https://reviews.llvm.org/D149846

[OCaml] Rename link_modules' to link_modules

Commit 434e956 renamed link_modules to link_modules' for unclear reasons.
Based on the commit's diff, the author possibly intended to have two
functions, link_modules to bind to LLVMLinkModules and link_modules' to
bind to LLVMLinkModules2. However, there is only one function. link_modules'
appears in LLVM 3.8 onwards.

Differential Revision: https://reviews.llvm.org/D153090

[clangd] Remove unused includes in IncludeCleaner.cpp, NFC

[InstCombine][AArch64] Fix phi insertion point

Fix the issue reported at https://reviews.llvm.org/rG724f4a5bac25#inline-9083,
by specifying the correct insertion point for the new phi.

[InstCombine] Regenerate test checks (NFC)

[GlobalISel][X86] Add handling of scalar G_USUBE opcodes

Extend the G_UADDE handling to also support G_USUBE

[X86] Fix callee side of receiving byval args on the stack

See the discussion in
https://discourse.llvm.org/t/generic-llvm-ir-windows-x64-argument-passing-issue-in-llvm-11-0-0-and-later/71350

D51842 implemented byval lowering for Win64. D83175 made the call
lowering honor the "from now on treat this as a regular pointer" comment
also when the argument gets passed on the stack. However, it didn't
update the callee side.

Differential revision: https://reviews.llvm.org/D153020

[clangd] Skip function parameter decls when evaluating variables on hover.

Differential Revision: https://reviews.llvm.org/D153015

[mlir][nvvm] Introduce `mbarrier.arrive`

It introduces `mbarrier.arrive` that are in ptx78.

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D153021

[mlir][nvvm] Introduce `mbarrier.inval`

Introduce support for PTX's `mbarrier.inval` .

Contiunation of D151334

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D151338

[mlir][nvvm] Implement `mbarrier.init`

NV GPUs provides split arrive/wait barriers that one can syncronize a subgroup of threads in CTA. It is particularly important for Hopper GPUs and allows tracking engines like TMA. See for more details:
https://docs.nvidia.com/cuda/parallel-thread-execution/#parallel-synchronization-and-communication-instructions-mbarrier

This initial implementation sets the foundation for future enhancements and additions.

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D151334

[MC] Use regunits instead of MCRegUnitIterator. NFC.

Differential Revision: https://reviews.llvm.org/D153122

[bazel][mlir] Port 65305aeab99ad8ea09dd85e28a41c657152a08fb

[CGTypes] Remove recursion protection

With opaque pointers, it should no longer be necessary to protect
against recursion when converting Clang types to LLVM types, as
recursion can only be introduced via pointer types.

Differential Revision: https://reviews.llvm.org/D152999

[lldb] Remove unused directive from test for D153043

[GlobalISel][X86] Add s8/s16/s64 handling of G_UADDE opcodes

[Clang] Fix compare-record.c test on s390x (NFC)

s390x looks through pointers when determining the "externally
visible vector ABI". For that reason, the test shows different
behavior just on that platform.

Adjust the test in the reverse direction of what I originall did:
Make sure that the type behind the pointer is always queried, by
dereferencing the pointer.

[AMDGPU] Regenerate a few checks

[clang][Sema] Provide source range to several Wunused warnings

When the diagnosed function/variable is a template specialization, the source range covers the specialization arguments.
e.g.
```
warning: unused function 'func<int>' [-Wunused-function]
template <> int func<int> () {}
                ^~~~~~~~~
```
This comes in line with the printed text in the warning message. In the above case, `func<int>`

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D152707

[gn build] Port f873029386dd

[BOLT] Add minimal RISC-V 64-bit support

Just enough features are implemented to process a simple "hello world"
executable and produce something that still runs (including libc calls).
This was mainly a matter of implementing support for various
relocations. Currently, the following are handled:

- R_RISCV_JAL
- R_RISCV_CALL
- R_RISCV_CALL_PLT
- R_RISCV_BRANCH
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_GOT_HI20
- R_RISCV_PCREL_HI20
- R_RISCV_PCREL_LO12_I
- R_RISCV_RELAX
- R_RISCV_NONE

Executables linked with linker relaxation will probably fail to be
processed. BOLT relocates .text to a high address while leaving .plt at
its original (low) address. This causes PC-relative PLT calls that were
relaxed to a JAL to not fit their offset in an I-immediate anymore. This
is something that will be addressed in a later patch.

Changes to the BOLT core are relatively minor. Two things were tricky to
implement and needed slightly larger changes. I'll explain those below.

The R_RISCV_CALL(_PLT) relocation is put on the first instruction of a
AUIPC/JALR pair, the second does not get any relocation (unlike other
PCREL pairs). This causes issues with the combinations of the way BOLT
processes binaries and the RISC-V MC-layer handles relocations:
- BOLT reassembles instructions one by one and since the JALR doesn't
  have a relocation, it simply gets copied without modification;
- Even though the MC-layer handles R_RISCV_CALL properly (adjusts both
  the AUIPC and the JALR), it assumes the immediates of both
  instructions are 0 (to be able to or-in a new value). This will most
  likely not be the case for the JALR that got copied over.

To handle this difficulty without resorting to RISC-V-specific hacks in
the BOLT core, a new binary pass was added that searches for
AUIPC/JALR pairs and zeroes-out the immediate of the JALR.

A second difficulty was supporting ABS symbols. As far as I can tell,
ABS symbols were not handled at all, causing __global_pointer$ to break.
RewriteInstance::analyzeRelocation was updated to handle these
generically.

Tests are provided for all supported relocations. Note that in order to
test the correct handling of PLT entries, an ELF file produced by GCC
had to be used. While I tried to strip the YAML representation, it's
still quite large. Any suggestions on how to improve this would be
appreciated.

Reviewed By: rafauler

Differential Revision: https://reviews.llvm.org/D145687

[DWARFLinker][Reland] Handle DW_OP_GNU_push_tls_address while check for variable location.

The D147066 changed the way how DWARF location expressions are handled.
Now expressions are parsed and their operands are analysed. New handling
misses the DW_OP_GNU_push_tls_address extention. This patch adds handling
DW_OP_GNU_push_tls_address while checking for addresses.

Differential Revision: https://reviews.llvm.org/D153010

[mlir][ArmSME] Insert intrinsics to enable/disable ZA

This patch adds two LLVM intrinsics to the ArmSME dialect:

  * llvm.aarch64.sme.za.enable
  * llvm.aarch64.sme.za.disable

for enabling the ZA storage array [1], as well as patterns for inserting
them during legalization to LLVM at the start and end of functions if
the function has the 'arm_za' attribute (D152695).

In the future ZA should probably be automatically enabled/disabled when
lowering from vector to SME, but this should be sufficient for now at
least until we have patterns lowering to SME instructions that use ZA.

N.B. The backend function attribute 'aarch64_pstate_za_new' can be used
manage ZA state (as was originally tried in D152694), but it emits calls
to the following SME support routines [2] for the lazy-save mechanism
[3]:

  * __arm_tpidr2_restore
  * __arm_tpidr2_save

These will soon be added to compiler-rt but there's currently no public
implementation, and using this attribute would introduce an MLIR
dependency on compiler-rt. Furthermore, this mechanism is for routines
with ZA enabled calling other routines with it also enabled. We can
choose not to enable ZA in the compiler when this is case.

Depends on D152695

[1] https://developer.arm.com/documentation/ddi0616/aa
[2] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-routines
[3] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#the-za-lazy-saving-scheme

Reviewed By: awarzynski, dcaballe

Differential Revision: https://reviews.llvm.org/D153050

Revert "[DWARFLinker] Handle DW_OP_GNU_push_tls_address while check for variable location."

This reverts commit e89738451a3830d80fcf23554fd0b297bca60266.

[AMDGPU][GFX11] Add test coverage for 16-bit conversions, part 15.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D152908

[mlir][ArmSME] Extend streaming-mode pass to support enabling ZA

This patch extends the 'enable-arm-streaming' pass with a new option to
enable the ZA storage array by adding the 'arm_za' attribute to
'func.func' ops.

A later patch will insert `llvm.aarch64.sme.za.enable` at the beginning
of 'func.func' ops and `llvm.aarch64.sme.za.disable` before
`func.return` statements when lowering to LLVM dialect.

Currently the pass only supports enabling ZA with streaming-mode on but
the SME LDR, STR and ZERO instructions can access ZA when not in
streaming-mode (section B1.1.1, IDGNQM [1]), so it may be worth making
these options independent in the future.

N.B. This patch is generally useful in the context of SME enablement in
MLIR, but it will help enable writing an integration test for rewrite
pattern that lowers `vector.transfer_write` -> `zero {za}` (D152508).

[1] https://developer.arm.com/documentation/ddi0616/aa

Reviewed By: awarzynski, dcaballe

Differential Revision: https://reviews.llvm.org/D152695

[AMDGPU][GFX11] Add test coverage for 16-bit conversions, part 11.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D152904

[RISCV][NFC] Simplify code.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D153095

[DWARFLinker] Handle DW_OP_GNU_push_tls_address while check for variable location.

The D147066 changed the way how DWARF location expressions are handled.
Now expressions are parsed and their operands are analysed. New handling
misses the DW_OP_GNU_push_tls_address extention. This patch adds handling
DW_OP_GNU_push_tls_address while checking for addresses.

Differential Revision: https://reviews.llvm.org/D153010

[mlir][llvm] Add memcpy support for mem2reg/sroa.

This revision introduces SROA and mem2reg support for the family of
memcpy-like intrinsics (memcpy, memcpy.inline and memmove).

The mem2reg implementation transforms memcpys of full types into loads
and store. Memcpy between two promotable slots always disappear.

The SROA implementation transforms memcpys of *entire* aggregate types
into memcpys of all of their fields.

Reviewed By: gysit

Differential Revision: https://reviews.llvm.org/D152898

[LoongArch] Some cleanup and readability improvements to LoongArchISelLowering.cpp, NFC

[include-cleaner] Reorder SymbolReference fields to avoid padding space, NFC

This will bring down the size from 40 bytes to 32 bytes.

Differential Revision: https://reviews.llvm.org/D153018

[clang][Interp] Handle LambdaExprs

Differential Revision: https://reviews.llvm.org/D146030

[llvm-exegesis] Use MCJIT only for execution

Initially, llvm-exegesis was generating the benchmark code for the
host CPU to execute it inside its own process. Thus, MCJIT was reused
for fetching function's bytes to fill the assembled_snippet field in
the benchmark report.

Later, the --mtriple and --benchmark-phase command line options were
introduced that are handy for testing snippet generation even if
snippet execution is not possible. In that setup, MCJIT is asked to
parse an object file for a foreign CPU or operating system that is
probably not guaranteed to succeed and was actually observed to fail
in https://reviews.llvm.org/D145763.

This commit implements a much simplified function's code fetching,
assuming the benchmark function is the only function in the object file
and it spans across the entire text section (note that MCJIT-based code
has more or less the same assumption - see TrackingSectionMemoryManager
class).

~~~

Huawei RRI, OS Lab

Reviewed By: courbet

Differential Revision: https://reviews.llvm.org/D148921

[clang] Don't create import decls without -fmodules

When modules are disabled, there's no loaded module for these import
decls to point at. This results in crashes when there are modulemap
files but no -fmodules flag (this configuration is used for layering
check violations).

This patch makes sure import declarations are introduced only when
modules are enabled, which makes this case similar to textual headers
(no import decls are created for #include of textual headers from a
modulemap).

Differential Revision: https://reviews.llvm.org/D152274

[RISCV] Fix spelling Compess->Compress. Fix 80 columns. NFC

Remove clang/ModuleInfo.txt

The script build-for-llvm-top.sh and LLVM's ModuleInfo.txt are gone
since a long time (commit d20ea7dc59 in November 2011), and llvm-top
itself has even been removed from llvm-archive (it can be found here:
https://github.com/llvm/llvm-archive/tree/cab7f8f160f0bd8d20d9a4036aa4083f2bc2740a/llvm-top
) so delete Clang's ModuleInfo.txt as well.

Differential Revision: https://reviews.llvm.org/D152995

Revert "[lldb] Rate limit progress reports -- different approach [WIP-ish]"

This reverts commit c30853460da7446f92bc1e516f9cbe2c5df6e136, which I
pushed accidentally -- sorry.

[lldb] Fix MainLoopTest for changes in D152712

[lldb] Rate limit progress reports -- different approach [WIP-ish]

Have the Progress class spawn a thread to periodically send progress
reports.

The reporting period could be made configurable, but for now I've
hardcoded it to 100ms. (This is the main WIP part)

It could be argued that creating a thread for progress reporting adds
overhead, but I would counter that by saying "If the task is so fast
that creating a thread noticably slows it down, then it really doesn't
need progress reporting".

For me, this speeds up DWARF indexing by about 1.5% (which is only
slightly above the error bars), but I expect it will have a much bigger
impact in situations where printing a single progress update takes a
nontrivial amount of time.

Differential Revision: https://reviews.llvm.org/D152364

[RISCV] relaxDwarfCallFrameFragment: remove unneeded relocations for relaxation

If `evaluateAsAbsolute(Value, Layout.getAssembler())` returns true, we
know the address delta is a constant and can suppress relocations
(usually SET6/SUB6).

While here, replace two evaluateKnownAbsolute calls (subtle; avoid if possible)
with evaluateAsAbsolute.

[lldb] Fix handling of cfi_restore in the unwinder

Currently, lldb's unwinder ignores cfi_restore opcodes for registers
that are not set in the first row of the unwinding info. This prevents
unwinding of failed assertion in Chrome/v8 (https://github.com/v8/v8).
The attached test is an x64 copy of v8's function that failed to unwind
correctly (V8_Fatal).

This patch changes handling of cfi_restore to reset the location if
the first unwind table row does not map the restored register.

Differential Revision: https://reviews.llvm.org/D153043

[LICM] Sunk instructions with invalid source location.

Building the given test case with 'clang -O2 -g' the call to
'getInOrder' is sunk out of the loop by LICM, but the source
location is not dropped.

Reviewed By: aprantl, fdeazeve

Differential Revision: https://reviews.llvm.org/D152691

[AIX][tests] Temporarily disable test index-with-module.m

This test is failing on AIX due to patch D151938. Disable it for now to get the bot green while we investigate.

[CGP] Additional tests for removing operand of assume. NFC.

[AIX] Disable test for missing DWARF section

This new test is failing on AIX due to an unsupported DWARF section, so disable it (same rationale as patch D111336).

[lldb][TerminalTest] Fix assertion failure

D152712 replaced `llvm::sys::RetryAfterSignal(-1, ::open)` with
`FileSystem::Instance().Open` for bionic in PseudoTerminal::OpenSecondary, and
FileSystem::Instance() is failing with assertion on arm Linux.

The assertion should be FileSystem re-initialization check, therefore the
hypothesis is that TerminalTest tests are initializing FileSystem instance
repeatedly.

Use SubsystemRAII<FileSystem> to ensure tearing down the FileSystem instance.

Differential Revision: https://reviews.llvm.org/D153091

[MC][test] Add some label difference tests

[RegAlloc] Simplify RegAllocEvictionAdvisor::canReassign (NFC)

Use range-based for loops.
The return type has been changed to bool because the method is only
used in boolean contexts.

Reviewed By: mtrofin

Differential Revision: https://reviews.llvm.org/D152665

[MC] Add MCRegisterInfo::regunits for iteration over register units

Reviewed By: foad

Differential Revision: https://reviews.llvm.org/D152098

[MC] Merge MC[Sub,Super]RegIterator with mc_[sub,super]_reg_iterator

Turn MC*RegIterator into fully qualified iterators by deriving them from
iterator_adaptor_base. This makes mc_*_reg iterators redundant.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D152655

[DAG] Unroll opereand when its type is illegal for ldexp.

Reviewed By: pengfei

Differential Revision: https://reviews.llvm.org/D152997

Revert "[CodeGen] Disable default copy ctor and copy assignment operator for class Array"

This reverts commit 466678b5202052dcd38fdfc3f764fb5d5de7c34b.

[MC] Improve .subsection diagnostic

lldb [NFC] Add logging to Process when address masks are updated

To aid in integration testing/debugging. Verifying that the address
mask/addressable bits values from different sources are correctly
registered by lldb.

[mlir][doc] Fix the layout of the table for the tosa.cast permissible operations

We can make the table for the `tosa.cast` permissible operations readable by utilizing the markdown table format.

{F27924602}

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D152992

[mlir][sparse] enhance element-wise fusion heuristics

We prevent merging a sparse-in/dense-out with dense-in
kernels because the result is usuall not sparsifiable.
Dense kernels and sparse kernels are still fused, obviously.

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D153077

[mlir][sparse][gpu] recognizing sddmm pattern in GPU libgen path

Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D151582

[scudo] Disable OddEvenTags by default.

Scudo has zero-tagged headers between any two allocation that will catch
a linear buffer overflow of up to 16 bytes. OddEvenTags extends this
guarantee to one chunk of the given SizeClass at the cost of the reduced
entropy for all heap tags (i.e. lower chance to catch use-after-free and
large overflows).

Given that the first 16 bytes are already deterministic, I feel this is
a bad tradeoff.

Differential Revision: https://reviews.llvm.org/D152984

[compiler-rt] Go back to using the 32-bit allocator for Fuchsia+RISCV64

Due to logic in the 64-bit allocator, the smallest allocation we can
zx_vmar_allocate is 2^37 bytes, but this is too large to allocate for
the standalone lsan allocator on a 39-bit VMA. This leads to the
zx_vmar_allocate call when initially setting up the allocator to fail.
This is similar to what android experiences on a 64-bit system with a
small vma. (See sanitizer_allocator_test.cpp).

This effectively reverts f6c4808d95221a5838e14474d95c6fe85bb1488a and
has Fuchsia use the 32-bit allocator for RISCV.

[Sanitizers] Remove unused parameter from COMMON_INTERCEPTOR_MUNMAP_IMPL

This was a result of copy/paste from the MMAP interceptor which uses the parameter to swtich between mmap and mmap64.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D152980

[MC] Remove unneeded special cases from AttemptToFoldSymbolOffsetDifference

[scudo] Do not compile timing.cpp if LLVM_LIBC_INCLUDE_SCUDO=on

Temporary hack until LLVM libc supports inttypes.h print format macros

timing.h uses the PRId64 macro which is not included in llvm libc yet

Bug: https://github.com/llvm/llvm-project/issues/63317

Reviewed By: michaelrj, thesamesam, Chia-hungDuan

Differential Revision: https://reviews.llvm.org/D152979

[CGCall] Prune ArgStruct [-Wunused-variable]

It has been unused since b92ccc355acb

Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

Got rid of non-determinism in MetadataLoader.cpp.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>
Differential Revision: https://reviews.llvm.org/D144004

Add a fatal error for debug builds when disagreement about stepping

On one CI bot we're seeing a failure where the kernel reports that
we have completed an instruction step (via a mach exception) and
lldb doesn't think the thread was doing an instruction step.  It
takes the conservative approach of stopping at this point, breaking
tests.

This patch adds an llvm fatal error for debug builds where it will
log the state of the thread and the AArch64 ESR, to confirm what
the hardware reported as the exception so we can double check the
kernel's interpretation.

I'll change this to an lldbassert without the runtime details in
the string once we have an idea what is happening.  the hope is
that this will get hit on the CI bot soon.

Differential Revision: https://reviews.llvm.org/D153079

[scudo] Group MappedUser/AllocatedUser into PagesInfo (NFC)

Create a new PagesInfo to contain all the information about pages. This
is the preparation of adding new lock for page operations.

Note that primary32 hasn't switched to MemMap. Will add PagesInfo later
when we move to MemMap in primary32.

Differential Revision: https://reviews.llvm.org/D149142

[scudo] Group poppedBlocks/pushedBlocks into BlocksInfo (NFC)

Create a new BlocksInfo to contain a list of blocks, poppedBlocks and
pushedBlocks. This is the preparation of adding new lock for operations
on freelist.

Differential Revision: https://reviews.llvm.org/D149143

[llvm-cov] Normalize paths by removing dots

We were producing inconsistent results when a file appeared multiple
times in gcno/gcda files if the instances had differing relative paths.

This patch unifies filenames, so coverage results are merged.

Patch by Oleksii Odynochenko. Thanks!

Differential Revision: https://reviews.llvm.org/D152453

[RISCV] Prevent vsetvli insertion from deleting some vsetvli instructions

If the result register is used, it is not safe to delete.

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D153076

[MC] Remove unneeded isUndefined() for isSymbolRefDifferenceFullyResolved. NFC

The only caller `AttemptToFoldSymbolOffsetDifference` has performed the same
checks.

[lldb][NFCI] Remove use of ConstString from IOHandler

None of these need to be in the ConstString StringPool. For the most
part they are constant strings and do not require fast comparisons.

I did change IOHandlerDelegateMultiline slightly -- specifically, the
`m_end_line` member always has a `\n` at the end of it now. This was so
that `IOHandlerGetControlSequence` can always return a StringRef. This
did require a slight change to `IOHandlerIsInputComplete` where we must
drop the newline before comparing it against the input parameter.

Differential Revision: https://reviews.llvm.org/D151597

[lldb] Symtab::SectionFileAddressesChanged should clear the file address map instead of name map

Currently, `SectionFileAddressesChanged` clears out the `name_to_index`
map and sets `m_file_addr_to_index_compute` to false. This is strange,
as these two fields are used for different purposes. What we should be
doing is clearing the file address to index mapping.

There are 2 bugs here:
1. If we call SectionFileAddressesChanged after the name indexes have
   been computed, we end up with an empty name to index map, so lookups
   will fail. This doesn't happen today because we don't initialize the
   name indexes before calling this, but this is a refactor away from
   failing in this way.
2. Because we don't clear `m_file_addr_to_index` but still set it's
   computed flag to false, it ends up with twice the amount of
   information. One entry will be correct (since it was recalculated),
   one entry will be outdated.

rdar://110192434

Differential Revision: https://reviews.llvm.org/D152579

[GlobalISel][X86] Add i128 add/sub test coverage for narrowing on x86_64 triples

[GlobalIsel][X86] Avoid IMPLICIT_DEF in irregular types for CTTZ/CTLZ legalization tests

IMPLICIT_DEF can lead to some pretty weird G_UNMERGE_VALUES of long lists of s1 values, try to use a real source value instead

[CUDA] Updated CUDA versions mentioned in CompileCudaWithLLVM.rst

[lldb][Android] Use a lambda for calls to ::open in RetryAfterSignal

lldb-server for Android does not build with NDK r21 and above due to
RetryAfterSignal and Bionic ::open mismatch.
https://github.com/llvm/llvm-project/issues/54727

Apply the LLVM patch to LLDB.
https://github.com/llvm/llvm-project/commit/0a0e411204a2baa520fd73a8d69b664f98b428ba

> In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing
> compile errors of RetryAfterSignal due to overload resolution. Wrapping
> the call in a lambda avoids this.

Differential Revision: https://reviews.llvm.org/D152712

[SimplifyCFG] Add textual pass params for FoldTwoEntryPHINode and SimplifyCondBranch

[RISCV][InsertVSETVLI] Treat vmv.v.i as-if it were vmv.s.x when VL=1, and inactive lanes are undefined

A vmv.v.i/x splats the immediate to all active lanes. For the active lanes, this is the same as vmv.s.x which inserts one scalar into the low lane. If we can ignore all the inactive lanes (because they are known undefined), then the two are semantically equivalent. We already reason about compatible VL/VTYPE combinations for vmv.s.x, apply the same logic to vmv.v.i.

Unlike a vmv.s.x, we do need to be careful not to increase LMUL. A splat instruction is probably linear in LMUL, so restrict this to LMUL1.

Differential Revision: https://reviews.llvm.org/D152845

[mlir][sparse] using stable_sort to make sure the compiled code are consistent between different builds configuration

Reviewed By: aartbik

Differential Revision: https://reviews.llvm.org/D153074

[mlir][sparse] proper in-place SDDMM with spy function

This specific operation matches the cuSPARSE SDDMM semantics exactly.

Reviewed By: Peiming

Differential Revision: https://reviews.llvm.org/D152969