Update the documentation to reference lldbassert rather than
lldb_assert. The latter is the implementation, which shouldn't be used
directly. Instead, users should use lldbassert which is the macro that
expands to assert or lldb_assert depending on the build type.

The MachineUA now queries the target to determine if a given register holds a
uniform value. This is determined using the corresponding register bank if
available, or by a combination of the register class and value type. This
assumes that the target is optimizing for performance by choosing registers, and
the target is responsible for any mismatch with the inferred uniformity.

For example, on AMDGPU, an SGPR is now treated as uniform, except if the
register bank is VCC (i.e., the register holds a wave-wide vector of 1-bit
values) or equivalently if it has a value type of s1.

 - This does not always work with inline asm, where the register bank or the
   value type might not be present. We assume that the SGPR is uniform, because
   it is not expected to be s1 in the vast majority of cases.
 - The pseudo branch instruction SI_LOOP is now hard-coded to be always
   divergent, although its condition is an SGPR.

Reviewed By: arsenm

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

Fixes https://github.com/llvm/llvm-project/issues/62715

If a select's condition is a trivial select:
```
%s = select %cond, i1 true, i1 false
```
Unswitch on %cond, rather than %s. This fixes crashes where there is a
disparity in finding candidates and and the transformation logic.

llvm-exegesis has both a capture mode and an analysis mode that can be
used independently of each other. This patch makes it clear that
analysis mode will work on other platforms that LLVM supports in the
documentation which was unclear before.

Reviewed By: courbet

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

[NFC] [C++20] [Modules] Rename ASTContext::getNamedModuleForCodeGen to ASTContext::getCurrentNamedModule

The original name "ASTContext::getNamedModuleForCodeGen" is not properly
reflecting the usage of the interface. This interface can be used to
judge the current module unit in both sema analysis and code generation.
So the original name was not so correct.

Before:

```
module x
    #( //
        parameter x)
    ( //
        input y);
endmodule
```

After:

```
module x
    #(//
      parameter x)
    (//
     input y);
endmodule
```

If the first line in a port or parameter list is not a comment, the
following lines will be aligned to the first line as intended:

```
module x
    #(parameter x1,
      parameter x2)
    (input y,
     input y2);
endmodule
```

Previously, the indentation would be changed to an extra continuation
indentation relative to the start of the parenthesis or the hash if
the first token inside the parentheses was a comment.  It is a feature
introduced in ddaa9be9.  The feature enabled one to insert a `//`
comment right after an opening parentheses to put the function
arguments on a new line with a small indentation regardless of how
long the function name is, like this:

```
someFunction(anotherFunction( // Force break.
    parameter));
```

People are unlikely to use this feature in a Verilog port list because
the formatter already puts the port list on its own lines.  A comment
at the start of a port list is probably a comment for the port on the
next line.

We also removed the space before the comment so that its indentation
would be same as that for a line comment anywhere else in the port
list.

Reviewed By: HazardyKnusperkeks

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

If LLVM is built with a compiler other than clang, the `compile_commands.json`
file may contain compiler flags unknown by clang.  When a clangd test is copied
into the build directory and checked, clangd will pick the unknown flag from
the file and cause a test failure.  Create an empty `compile_commands.json` in
the test directory nested in the build directory to override it.

Reviewed By: thesamesam

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

This reverts commit f109b101 as required
in
https://github.com/llvm/llvm-project/commit/f109b1016801e2b0dbee278f3c517057c0b1d441#commitcomment-113477829.

dependent on f109b101

Given
https://github.com/llvm/llvm-project/commit/f109b1016801e2b0dbee278f3c517057c0b1d441#commitcomment-113477829,
we need to revert f109b101. So it will be better to make this patch not
dependent on f109b101 as much as possible.

In the CoarrayChecker, add checks for the constraints C1177 and
C1178 for event-wait-stmt. Add event-post-stmt to the check
for the constraints for sync-stat-list. Add a check for the
constraint C1176 on event-variable.

Reviewed By: PeteSteinfeld

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

[RISCV][MC] .debug_line/.debug_frame/.eh_frame: emit relocations for assembly input files with relaxation

When assembling `.debug_line` for both explicitly specified and synthesized
`.loc` directives. the integrated assembler may incorrectly omit relocations for
-mrelax.

For an assembly file, we have a `MCAssembler` object and `evaluateAsAbsolute`
will incorrectly fold `AddrDelta` to a constant (which is not true in the
presence of linker relaxation).
`MCDwarfLineAddr::Emit` will emit a special opcode, which does not take into
account of linker relaxation. This is a sufficiently complex function that
I think should be called in any "fast paths" for linker relaxation aware assembling.

The following script demonstrates the bugs.

```
cat > x.c <<eof
void f();
void _start() {
  f();
  f();
  f();
}
eof
# C to object file: correct DW_LNS_fixed_advance_pc
clang --target=riscv64 -g -c x.c
llvm-dwarfdump --debug-line -v x.o | grep \ DW_LNS_fixed_advance_pc -q

# Assembly to object file with synthesized line number information: incorrect special opcodes
clang --target=riscv64 -S x.c && clang --target=riscv64 -g -c x.s
llvm-dwarfdump --debug-line -v x.o | grep \ DW_LNS_fixed_advance_pc -q; test $? -eq 1

# Assembly with .loc to object file: incorrect special opcodes
clang --target=riscv64 -S -g x.c && clang --target=riscv64 -c x.s
llvm-dwarfdump --debug-line -v x.o | grep \ DW_LNS_fixed_advance_pc -q; test $? -eq 1
```

The `MCDwarfLineAddr::Emit` code path is an old optimization in commit
57ab708b (2010) that seems no longer relevant.
It don't trigger for direct machine code emission (label differences are not
foldable without a `MCAssembler`). MCDwarfLineAddr::Emit does complex operations
that are repeated in MCAssembler::relaxDwarfLineAddr, which an intricate RISCV
override.

Let's remove the "fast path". Assembling the assembly output of
X86ISelLowering.cpp with `-g` may be 2% slower, but I think the cost is fine.
There are opportunities to make the "slow path" faster, e.g.

* Optimizing the current new MC*Fragment pattern that allocates new fragments on
  the heap.
* Reducing the number of relaxation times for .debug_line and .debug_frame, as
  well as possibly other sections using LEB128. For instance, LEB128 can have a
  one-byte estimate to avoid the second relaxation iteration.

For assembly input with -mno-relax, in theory we can prefer special opcodes to
DW_LNS_fixed_advance_pc to decrease the size of .debug_line, but such a change
may be overkill and unnecessarily diverge from -mrelax behaviors and GCC.

---

For .debug_frame/.eh_frame, MCDwarf currently emits DW_CFA_advance_loc without
relocations. Remove the special case to enable relocations. Similar to
.debug_line, even without the bug fix, the MCDwarfFrameEmitter::encodeAdvanceLoc
special case is a sufficiently complex code path that should be avoided.

---

When there are more than one section, we generate .debug_rnglists for
DWARF v5. We currently emit DW_RLE_start_length using ULEB128, which
is incorrect. The new test gen-dwarf.s adds a TODO.

---

About other `evaluateAsAbsolute` uses. `MCObjectStreamer::emit[SU]LEB128Value`
have similar code to MCDwarfLineAddr. They are fine to keep as we don't have
LEB128 relocations to correctly represent link-time non-constants anyway.

---

In the future, we should investigate ending a MCFragment for a relaxable
instruction, to further clean up the assembler support for linker relaxation
and fix `evaluateAsAbsolute`.

See bbea6425 for some of the related code.

Reviewed By: enh, barannikov88

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

Reviewed By: Peiming

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

Consecutive element-wise negate should be canonicalized as no-op.

Reviewed By: eric-k256

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

Link to specification: [riscv-non-isa/rvv-intrinsic-doc#221](https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/221)

Reviewed By: craig.topper

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

This reverts commit ae337ed5.

Still causes miscompiles, see D141188.

On incremental scan, caching an out-of-date PCM on the VFS layer causes each TU and each module to recompile the PCM again. This is huge performance problem. Stop caching ".pcm" files.

Reviewed By: Bigcheese

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

This reverts commit d1e00b6f.

Internally, there were issues with caching stat failures for .framework directories. We need some time for investigation to pinpoint what exactly was going wrong.

This applies the same trick for Lua that I did for python in
27b6a4e6.

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

Reviewed By: nikic

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

I have upcoming changes break with invalid Function definitions.

Reviewed By: aidengrossman, courbet

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

This allows `index` vectors to be converted to SPIR-V.

Reviewed By: ThomasRaoux

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

As for now, 'extract_symbols.py' can use several tools to extract
symbols from object files and libraries and to guess if the target is
32-bit Windows. The tools are being found via PATH, so in most cases,
they are just system tools. This approach has a number of limitations,
in particular:

* System tools may not be able to handle the target format in case of
  cross-platform builds,
* They cannot read symbols from LLVM bitcode files, so the staged LTO
  build with plugins is not supported,
* The auto-selected tools may be suboptimal (see D113557),
* Support for multiple tools for a single task increases the complexity
  of the script code.

The patch proposes using LLVM's own tools to solve these issues.
Specifically, 'llvm-readobj' detects the target platform, and 'llvm-nm'
reads symbols from all supported formats, including bitcode files. The
tools can be built in Release mode for the host platform or overridden
using CMake settings 'LLVM_READOBJ' and 'LLVM_NM' respectively. The
implementation also supports using precompiled tools via
'LLVM_NATIVE_TOOL_DIR'.

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

Otherwise we're just rewriting the currently saved module instead of the newly reduced one.

Doesn't affect the final output since we separately write that at the end.

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

Add some debug output to `outline` to assist in debugging + understanding the
code.

This will say

- How many things we found worth turning into outlined functions
- Whether or not candidates were pruned via the outlining algorithm
- The function created (if it was created)
- Where the calls were inserted
- What instruction was used to create the call

Sample output below:

```
NUMBER OF POTENTIAL FUNCTIONS: 5
WALKING FUNCTION LIST
PRUNED: 0/2 candidates
OUTLINE: Expected benefit (12 B) > threshold (1 B)
NEW FUNCTION: OUTLINED_FUNCTION_0
CREATE OUTLINED CALLS
  CALL: OUTLINED_FUNCTION_0 in bar:<unknown>
   .. BL @OUTLINED_FUNCTION_0, implicit-def $lr, implicit $sp
  CALL: OUTLINED_FUNCTION_0 in bar:<unknown>
   .. BL @OUTLINED_FUNCTION_0, implicit-def $lr, implicit $sp
PRUNED: 2/2 candidates
SKIP: Expected benefit (0 B) < threshold (1 B)
PRUNED: 0/2 candidates
OUTLINE: Expected benefit (8 B) > threshold (1 B)
NEW FUNCTION: OUTLINED_FUNCTION_1
CREATE OUTLINED CALLS
  CALL: OUTLINED_FUNCTION_1 in bar:<unknown>
   .. BL @OUTLINED_FUNCTION_1, implicit-def $lr, implicit $sp
  CALL: OUTLINED_FUNCTION_1 in bar:<unknown>
   .. BL @OUTLINED_FUNCTION_1, implicit-def $lr, implicit $sp
PRUNED: 2/2 candidates
SKIP: Expected benefit (0 B) < threshold (1 B)
PRUNED: 2/2 candidates
SKIP: Expected benefit (0 B) < threshold (1 B)
```

When `ValueObjectPrinter` calls its `m_decl_printing_helper`, not all state is passed to
the helper. In particular, the helper doesn't have access to `m_curr_depth`, and thus
can't act on the logic within `ShouldShowName`.

To address this, this change passes in a modified copy of `m_options`. The modified copy
has has `m_hide_name` set according to the results of `ShouldShowName`. This allows
helper functions to know whether the name should be shown or hidden, without having
access to `ValueObjectPrinter`'s full state.

This is NFC in mainline lldb, as the only decl printing helper doesn't make use of this.
However in swift-lldb at least, there are decl printing helpers that do need this
information passed to them. See https://github.com/apple/llvm-project/pull/6795 where a
test is also included.

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

This adds QuantizationDialect to the dependent dialects of TOSA
This fixes the intermittent bug when creating uniform quantized type when none was parsed in.

LLVM ERROR: can't create type 'mlir::quant::UniformQuantizedType' because storage uniquer isn't initialized: the dialect was likely not loaded, or the type wasn't added with addTypes<...>() in the Dialect::initialize() method.

This happens, for example, in convert-tfl-uint8 pass when trying to create uniform quantized type i8 with zero-point=-128 to convert from ui8 type.

Signed-off-by: Tai Ly <tai.ly@arm.com>
Change-Id: I204248a45fd728d0cec8dc20214cb0b74de81e7b

Reviewed By: eric-k256

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

Reviewed By: ldionne, #libc

Spies: jloser, libcxx-commits

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

The second and third parameter of itaniumDemangle were removed in
commit 7277a72b ("[Demangle] remove unused params of itaniumDemangle")
Update a comment to reflect this.

Reviewed By: nathanchance

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

Set the C++ language standard before including LLDBStandalone.cmake.
Otherwise we risk building some of our dependencies (such as llvm_gtest)
without C++ 17 support.

This should fix the standalone bot [1] which is currently failing with the
following error:

  test-port.h:841:12: error: no member named 'tuple' in namespace 'std'
  using std::tuple;

[1] https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone

DissassemblerCreateInstance is a function pointer whos return type is
`Disassembler *`. But Disassembler::FindPlugin always returns a
DisassemblerSP, so there's no reason why we can't just create a
DisassemblerSP in the first place.

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

In 9c254184 `ASTWriter` stopped writing identifiers that are not interesting. Taking it a bit further, we don't need to sort the whole identifier table, just the interesting identifiers. This reduces the size of sorted vector from ~10k (including lots of builtins) to 2 (`__VA_ARGS__` and `__VA_OPT__`) in a typical Xcode project, improving `clang-scan-deps` performance.

Reviewed By: benlangmuir

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

Since 44363f2f various tests have started passing but introduced a
expression evaluation failure in TestDataFormatterSynthVal.py.
This patch marks the expression evaluation part as skipped while rest
of the test passes.
This patch aslo introduces a new helper isAArch64Windows in lldbtest.py.

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

Move areStatementsIdentical from BranchCloneCheck into ASTUtils.
Add small improvments. Use it in LoopConvertUtils.

Reviewed By: carlosgalvezp

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

This reverts commit e48826e0.

https://lab.llvm.org/buildbot/#/builders/219/builds/2520

ldb-shell :: SymbolFile/PDB/function-nested-block.test

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