This is needed to support things like null pointers.

Reviewed By: reames

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

The register list in the arg string is declared as `{$rlist}`. This patch removes the wrapping curly brackets because of the following:

- Curly brackets are the syntax for variant selection, e.g. given `X = {v0 | v1}`, the result after `CodeGenInstruction::FlattenAsmStringVariants` should be `X[AsmVariantNo]`.
- ARM also supports the register list, and they do not use the bracket wrapper.
- Parse of curly brackets are handled by `RISCVAsmParser::parseReglist`, the brackets in the td file do not correspond to asm syntax. Thus no testcase is affected.

So the curly brackets here are redundant and will become dangerous if RISCV needs more asm parser variants (took me several hours to figure out some wired assertion failures in a downstream fork)

Reviewed By: craig.topper

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

support DW_FORM_strx in dsymutil.

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

Sorting algorithms require strict weak ordering for comparators, final
fix for cmp instructions comparator.

This allows -mexec-model=reactor -shared produces a library module
with _initialize entrypoint, which is preferrable over __wasm_call_ctors.

This partially reverts https://reviews.llvm.org/D153293

Discussion: https://github.com/dicej/component-linking-demo/issues/3

Reviewed By: sbc100

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

Address post-commit simplification suggestion for 8a56179b: Replace
IsTruncated by conditionally setting TruncResultTy only if truncation
is required.

This reverts commit 1f34e282.

Test fails on x86-64 mac, see comments on https://reviews.llvm.org/rG1f34e282e8066281eb1447e21e44a2a2e9983e79.

As in all the other cpus from D134521, this adds FeatureFuseAdrpAdd to
NeoverseV2 to allow more linker relaxations.

Reviewed By: springerm

Re-land 691a2fab which was incorrectly
reverted.

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

This reverts commit 20966fcb.

Bot is broken https://lab.llvm.org/buildbot/#/builders/61/builds/47577

Generalize D127933 (Fuchsia special case) to other ELF targets. Ensure
that musl, NetBSD, OpenBSD, etc do not get ifunc codegen which is
unsupported in their rtld.

Link: https://discourse.llvm.org/t/does-ifunc-use-from-llvm-require-os-support/67628
Close: https://github.com/llvm/llvm-project/issues/64631

This reverts commit 691a2fab.

The bot is broken: https://lab.llvm.org/buildbot/#/builders/61/builds/47577

In case of unlimited polymorphic type, there is no derived type
spec, so use NoneType explicitly.

Reviewed By: tblah

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

SelectionDAG::getZeroExtendInReg does exactly the same masking.

The zext constant expression was detected by the fold, but then
handled as a sext. Use ZExtOperator instead of ZExtInst to handle
constant expressions.

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

The comment was out of date, the device libs build does provide all
the pointer overloads. An extremely pedantic interpretation of the
spec would suggest only the flat version exists, but the overloads do
exist in the implementation.

https://reviews.llvm.org/D156720

If we can fit an entire vector of i1 into a single element, e.g. v32i1 ->
v1i32, then we can reverse it via vbrev.v.
We need to handle the case where the vector doesn't exactly fit into the larger
element type, e.g. v4i1 -> v1i8. In this case we shift up the reversed bits
afterwards.

Reviewed By: fakepaper56, 4vtomat

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

https://reviews.llvm.org/D156708

Issue #10894 seems to claim this wasn't working. The test does seem to
work as intended, except the CHECKs added in
3ac4299d aren't doing anything since
it wasn't really using FileCheck.

Match how the generic implementation handles this. We now will leave
behind the dead other user for later passes to deal with.

https://reviews.llvm.org/D156707

This adds a RISC-V special case to ToolChain::GetDefaultDwarfVersion,
affecting Linux/Haiku/RISCVToolChain.

DWARF v5 .debug_loclists/.debug_rnglists's
DW_LLE_offset_pair/DW_RLE_offset_pair entry kinds utilitize `.uleb128 A-B`
directives where A and B reference local labels in code sections.
When A and B are separated by a RISC-V linker-relaxable instruction,
A-B is incorrectly folded without a relocation, causing incorrect debug
information.

```
void ext(void);
int foo(int x) {ext(); return 0;}
// DW_AT_location [DW_FORM_loclistx] of a DW_TAG_formal_parameter references a DW_LLE_offset_pair that can be incorrect after linker relaxation.

int ext(void);
void foo() { {
  int ret = ext();
  if (__builtin_expect(ret, 0))
    ext();
} }
// DW_AT_ranges [DW_FORM_rnglistx] of a DW_TAG_lexical_block references a DW_RLE_offset_pair that can be incorrect after linker relaxation.
```

D157657 will implement R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128
relocations, fixing the issue, but the relocation is only supported by
bleeding-edge binutils 2.41 and not by lld/ELF yet.

The goal is to make the emitted DWARF correct after linking.
Many users don't care about the default DWARF version, but a linker
error will be unacceptable. Let's just downgrade the default DWARF
version, before binutils>=2.41 is more widely available.

An alternative compatibility option is to add a toggle to DwarfDebug.cpp,
but that doesn't seem like a good idea.

Reviewed By: asb, kito-cheng

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

Make sure the function arguments are evaluated in a predictable
order.

This can be used to avoid `auto WarningHandler = ...`.
Similar to llvm-readobj.

D155723 changed the return type of getNames to a SmallVector of a different
size. However, it failed to also update the declaration of the variable that is
returned in such function.

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

This simplifies every use of MCRegUnitMaskIterator.

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

LLDB can benefit from having the base name of functions (i.e. without any
template parameters) as an entry into accelerator tables pointing back in the
DIE for the corresponding function specialization. In fact, some LLDB
functionality is only possible when those entries are present.

The DWARFLinker has been adding such entries for a while now, both with
apple_names and with debug_names. However, this has two side effects:

1. Some LLDB functionality is only possible when dsym bundles are present (i.e.
the linker touched the debug info).
2. The DWARFVerifier doesn't accept debug_name sections created by the linker,
as such names are (usually) neither the AT_name nor the AT_linkage_name of the
DIE.

Based on recent discussion [1], and because the DWARF 5 spec says that:

> A producer may choose to implement additional rules for what names are placed
> in the index

This patch relaxes the checks on the verifier to allow for simplified template
names in the accelerator table. To do so, we move some helper functions from
DWARFLinker into the core lib debug info. This addresses the point 2) above.

This patch also enables addressing point 1) in the future, since the helper
function is now visible to other parts of LLVM.

[1]: https://github.com/llvm/llvm-project/issues/58362

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

Fix static analyzer concern about null value
dereference. InterfacePointerType is dereferenced
and should not be null.

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

For scalar integer to float converts for Streaming Compatible SVE use
non-NEON version of convert instrction.

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

Reviewed By: springerm

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

Reviewed By: springerm

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

The tests of the mix-in classes of the Python bindings currently passed
even if the ops constructed by the mix-ins under test failed to verify.
This is because the assembled IR is still printed in generic form even
if it does not verify, and the `CHECK` statements are formulated in such
a lenient way that they also match that generic form. This patch adds
explicit verification to the decorator that is used for all test
functions.

Reviewed By: springerm

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

In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.

Reviewed By: #flang, kiranchandramohan

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

We were relying on a transitive include. This fixed
building the SPIRV backend.

Problem seem to be that on windows it says
  "Assertion failed: ...."
while one linux we get
  "Assertion ... failed."

Anyway, this fixup also limits the test case to x86_64-linux to
avoid buildbot failures due to such problems.

If the only purpose of the upgrade is a mangling change, this is
handled generically by intrinsic remangling, and does not require
any hand-written code.

This patch enables logical expressions to be used as arguments when the
default logical kind is changed (e.g. using -fdefault-integer-8) by
converting the type of the logical expression argument to the type of
the dummy argument in the function.

Reviewed By: klausler

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

Add two new helper functions `getBeforeBody` and `getAfterBody` to be consistent with "scf.for" (`getBody`) and to show in the API that both regions have exactly one block. Also simplify some code that assumed that there can be more than one block in a region.

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

When inspecting the function body, we can't simply ignore effects
of functions in the SCC entirely, because an argmem access of a
recursive call might result in an access to another location in
the callee.

Fix this by separately tracking memory effects that would occur if
the SCC accesses argmem, and then later add those.

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

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

If an argument is readnone we know that it isn't dereferenced. Then
it should be OK if that argument alias with a noalias argument.

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