All the new code should match the behavior of the old exactly.

Of note, the custom queries used to be implemented inside `HashedNameToDIE.cpp`
(which is the LLDB implementation of the tables). However, when porting to LLVM,
we believe they don't belong inside the LLVM table implementation:

1. They don't require any knowledge about the table itself
2. They are not relevant for other users of these classes.
3. They use LLDB data structures.

As such, we implement these custom queries inside AppleDWARFIndex.cpp.

Types and Objective-C tables are done separately, as they have slightly
different functionality that require rewriting more code.

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

When we only have a 16-bit pc-relative branch instruction we generate
a table of address for a jump table. Currently this is placed inline,
but this won't work with execute-only memory. In this case generate
the jump table out-of-line.

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

The sort of the elements in the GET_SUBTARGETINFO_MACRO block is done on
the "Name" field of each record. This field is not guaranteed to be unique,
is not guaranteed to even have a value at all, and is not used in the
output anyway. Change to sort on the "FieldName" field which should be
unique.

Problem spotted when lib/Target/PowerPC/PPCGenSubtargetInfo.inc changed
unexpectedly.

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

This patch extends the existing logic to handle cases where we have
branch conditions of the form (AND icmp, icmp) where the first icmp
implies the second. This can improve results in some cases, e.g. if
SimplifyCFG folded conditions from multiple branches to an AND.

The implementation handles this by adding a new type of check
(AndImpliedCheck), which are queued before conditional facts for the same
block.

When encountering AndImpliedChecks during solving, the first condition
is optimistically added to the constraint system, then we check if the
second icmp can be simplified, and finally the newly added entries are
removed.

The reason for doing things this way is to avoid clashes with signed
<-> unsigned condition transfer, which require us to re-order facts to
increase effectiveness.

Reviewed By: nikic, antoniofrighetto

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

This allows easier re-use of the checking logic. Split off from D151799.

Clean up exhaustive tests.  Let check functions return number of failures instead of passed/failed.

Reviewed By: sivachandra

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

This reverts commit f3ebd880 to pacify
windows-based buildbots.

I still think this should be done but should be done separately.

Use a unit test since I don't see any existing uses try to make use of
the high bits of a pointer.

This will also assert if the metadata type doesn't match the pointer
width, but I consider that a defect in the verifier and shouldn't be
handled.

AMDGPU allocates LDS globals by assigning !absolute_symbol with the
final fixed address. Tracking the high bits are 0 may help with
addressing mode matching.

BUG 1 - choosing the right cycle when booking a resource.
---------------------------------------------------------

Bottom up scheduling should take in account the current cycle at
the scheduling boundary when determing at what cycle a resource can be
issued. Supposed the schedule boundary is at cycle `C`, and that we
want to check at what cycle a 3 cycles resource can be instantiated.

We have two cases: A, in which the last seen resource cycle LSRC in
which the resource is known to be used is more than oe euqual to 3
cycles away from current cycle `C`, (`C - LSRC >=3`) and B in which
the LSRC is less than 3 cycles away from C (`C - LSRC < 3`). Note
that, in bottom-up scheduling LRS is always smaller or eaual to the
current cycle `C`.

The two cases can be schematized as follow:

```
... | C + 1 | C    | C - 1 | C - 2 | C - 3 | C - 4 | ...
    |       |      |       |       |       | LSRC  |   -> Case A
    |       |      |       | LSRC  |       |       |   -> Case B

// Before allocating the resource
LSRC(A) = C - 4
LSRC(B) = C - 2
```

In case A, the scheduler sees cycles `C`, `C-1` and `C-2` being
available for booking the 3-cycles resource. Therefore the LSRC can be
updated to be `C`, and the resource can be scheduled from cycle `C`
(the `X` in the table):

```
... | C + 1 | C    | C - 1 | C - 2 | C - 3 | C - 4 | ...
    |       | X    | X     | X     |       |       |  -> Case A
// After allocating the resource
LSRC(A) = C
```

In case B, the 3-cycle resource usage would clash with the LSRC if
allocated starting from cycle C:

```
... | C + 1 | C    | C - 1 | C - 2 | C - 3 | C - 4 | ...
    |       | X    | X     | X     |       |       |   -> clash at cycle C - 2
    |       |      |       | LSRC  |       |       |   -> Case B
```

Therefore, the cycle in which the resource can be scheduled needs to
be greater than `C`. For the example, the resource is booked
in cycle `C + 1`.

```
... | C + 1 | C    | C - 1 | C - 2 | C - 3 | C - 4 | ...
    | X     | X    | X     |       |       |       |
// After allocating the resource
LSRC(B) = C + 1
```

The behavior we need to correctly support cases A and B is obtained by
computing the next value of the LSRC as the maximum between:

1. the current cycle `C`;

2. and the previous LSRC plus the number of cycle CYCLES the resource will need.

In formula:

```
LSRC(next) = max(C, LSRC(previous) + CYCLES)
```

BUG 2 - booking the resource for the correct number of cycles.
--------------------------------------------------------------

When storing the next LSRC, the funcion `getNextResourceCycle` was
being invoked setting to 0  the number of cycles a resource was using.
The invocation of `getNextResourceCycle` is now using the values of
`Cycles` instead of 0.

Effects on code generation
--------------------------

This fix have effects only on AArch64, for the Cortex-A55
scheduling model (`-mcpu=cortex-a55`).

The changes in the MIR tests caused by this patch show that the value
now reported by `getNextResourceCycle` is correct.

Other cortex-a55 tests have been touched by this change, where some
instructions have been swapped. The final generated code is equivalent
in term of the total number of cycles. The test
`llvm/test/CodeGen/AArch64/misched-detail-resource-booking-02.mir`
shows in details the correctness of the bottom up scheduling, and the
effect on the codegen change that are visible in the test
`llvm/test/CodeGen/AArch64/aarch64-smull.ll`.

Reviewed By: andreadb, dmgreen

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

Constructors/destructors and OpenMP make use of single lane groups
in some cases.

I accidentally used `cast` instead of `cast_or_null`.

Reviewed By: sammccall, xazax.hun

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

I tried #pragma omp begin declare variant device_type(nohost) but it
didn't work and I'm not really sure how it's supposed to work.

Missing test from fd3437a4

Not sure if the standalone build case is supposed to be a supported
path. Should probably rely on find_package and imported targets
anyway.

If binary file specified as input with option --obj or -e is absent,
now llvm-addr2line exits immediately. This patch extends this behavior to
llvm-symbolizer. Previously llvm-symbolizer waited addresses from input
stream or command line in this case.

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

Release BlockFrequencyInfo and BranchProbabilityInfo results and other
per function information immediately afterwards, instead of holding
onto the memory until the next `CodeGenPrepare::runOnFunction` call.

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



Co-authored-by: Erik Hogeman <erik.hogeman@arm.com>

This is almost NFC except for the fact that:
- when multiple candidates are available we now return them in sorted order vs undetermined order previously
- the type of the transform return is relaxed an a test is added for the case where the transform does not apply

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

DWARFLinker puts three names for subprograms into the .apple_names and
.debug_names: short name, linkage name, name without template parameters.

DW_TAG_subprogram
   DW_AT_linkage_name "_Z3fooIcEvv"
   DW_AT_name "foo<char>"

short name: "foo<char>"
linkage name: "_Z3fooIcEvv"
name without template parameters: "foo"

DWARFv5 does not require stripping template parameters for subprogram name.
Current llvm-dwarfdump --verify reports the error if names stored in
accelerator table do not match with DIE name(name with stripped template
parameters stored in accelerator table does not match with original DIE name).
This patch does not store name without template parameters into the .debug_names table.

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

Recently eXecute Only (XO) codegen was also allowed for armv6-M. Previously this
was only implemented for ~armv7+, effectively if MOVW/MOVT is
available. Regarding long calls, we remove the check for MOVW/MOVT when
generating code for XO, which already was redundant as in the subtarget
initialization we already check if XO is valid for the target. And targets that
generate valid XO code should be able to handle the (wrapper globaladdress)
node.

Reviewed By: efriedma

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

X86's CMOV conversion transforms CMOV instructions into control flow between
blocks, meaning the value is computed by a PHI rather than a "real" machine
instruction. In instruction-referencing mode, we need to transfer the
instruction label between the old CMOV and the new PHI instruction to mark
where the variable value is computed.

There's an extra complication in that memory operands can be unfolded from the
CMOV and sunk into the new blocks -- the test checks both scenarios where the
instruction number has to hop between instructions.

This omission exposed by Dexter testing.

Reviewed By: Orlando

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

In order to placate the machine-verifier, X86CmovConversion needs to reset the
NoPHI property when it inserts a PHI.

Fixes buildbot failure: https://lab.llvm.org/buildbot/#/builders/16/builds/50453

Reviewed By: StephenTozer

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

Mutating join() isn't used and so appears to be an anti-optimization.
Having Lattice vs Environment inconsistent is awkward, particularly when trying
to minimize copies while joining.

This patch eliminates the difference, but doesn't actually change the signature
of join on concrete lattice types (as that's a breaking change).

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

When an assertion like the following fails:
   EXPECT_THAT(map, ElementsAre(Pair("p", "nullable"))));
Error message before:
   Actual: { 40-byte object <E8-A5 9C-7F 25-37 00-00 58-7E 51-51 D0-7F 00-00 00-00 00-00 00-00 00-00 01-00 00-00 00-00 00-00 00-DA C7-7F 25-37 00-00> }
After:
   Actual: { ("p", "nonnull") }

It is not ideal that we need to refer directly to DenseMapPair inside the
internal namespace, but I believe the practical maintenance risk is low.
This change is covered by DenseMap's unittests, as we've covered SmallString etc
in the past.

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

Precommit for D152258.

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

This reverts commit 091bfa76.

Depends On D153409

Reviewed By: xazax.hun

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

Reviewed By: sammccall, ymandel, gribozavr2, xazax.hun

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

We've been running this internally for months now, without any
stability or correctness concerns. It has ~40% speed up on incremental
diagnostics latencies (as preamble can get invalidated through code completion
etc.).

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

This will enable follow-up refactoring to use the State directly in the
constraint system, reducing the need to pass lots of arguments around.

Currently, we only return REGISTERS_UNAVAILABLE_FATAL if we receive
KERN_INVALID_ARGUMENT from thread_status. In reality, there are other
possible return values (MACH_SEND_INVALID_DEST for example) that make it
dangerous to read memory. This can be demonstrated by running
create_thread_leak.cpp in standalone mode where it will appear to hang
due to a EXC_BAD_ACCESS while scanning the stack.

This change reverses the current logic to treat MIG_ARRAY_TOO_LARGE as
non-fatal, and all other errors as fatal.

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

- Fix include paths for Transform Dialect Tutorial
- Add math dialect's pass into Pass.md
- Remove a include path of Quant dialect from Pass.md

Reviewed By: ftynse

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

This updates the documentation to match the implementation. Warning and
Min interact in the same way as Warning and Max.

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