In function `DeviceTy::getTargetPointer`, `Entry` could be `nullptr` because of
zero length array section. We need to check if it is a valid iterator before
using it.

Reviewed By: ronlieb

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

llvm/test/Bindings/Go is quite flaky in the past few months and nobody fixes it.

See

* https://lists.llvm.org/pipermail/llvm-dev/2021-December/154353.html "Suggestions on debugging pre-merge test failure that looks irrelevant."
* https://github.com/llvm/llvm-project/issues/53017

Reviewed By: aeubanks

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

There was a limitation in legality that in the original inner loop latch,
no instruction was allowed between the induction variable increment
and the branch instruction. This is because we used to split the
inner latch at the induction variable increment instruction. Since
now we have split at the inner latch branch instruction and have
properly duplicated instructions over to the split block, we remove
this limitation.

Please refer to the test case updates to see how we now interchange
loops where instructions exist between the induction variable increment
and the branch instruction.

Reviewed By: bmahjour

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

glibc versions < 2.26 use different names for the fields.
However the layout is unchanged, so using the offset should be a
portable way to address this issue across platforms.

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

Patch By: paulkirth

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

Add a convenience for appending constructed string values.

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

ExecutorAddr is the preferred representation for executor process addresses now.

We don't need to restrict operations on ExecutorAddrDiff as carefully as we do
for ExecutorAddr.

The current help for `frame variable` is somewhat long. Its length, combined
with the few aliases (`var`, `v`, and `vo`) can make the output of `apropos`
redundant and noisy.

This separates out the details into a separate long help.

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

Let each format of inst have two tests for it like other MxCMP
testcases.

Add 5 simple folders
* bitcast(x : T0, T0) -> x
* addrcast(x : T0, T0) -> x
* bitcast(bitcast(x : T0, T1), T0) -> x
* addrcast(addrcast(x : T0, T1), T0) -> x
* gep %x:T, 0 -> %x:T

Reviewed By: mehdi_amini

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

Extra definitions are placed in the generated source file for each op class. The substitution `$cppClass` is replaced by the op's C++ class name.

This is useful when declaring but not defining methods in TableGen base classes:

```
class BaseOp<string mnemonic>
    : Op<MyDialect, mnemonic, [DeclareOpInterfaceMethods<SomeInterface>] {
  let extraClassDeclaration = [{
    // ZOp is declared at at the bottom of the file and is incomplete here
    ZOp getParent();
  }];
  let extraClassDefinition = [{
    int $cppClass::someInterfaceMethod() {
      return someUtilityFunction(*this);
    }
    ZOp $cppClass::getParent() {
      return dyn_cast<ZOp>(this->getParentOp());
    }
  }];
}
```

Certain things may prevent defining these functions inline, in the declaration. In this example, `ZOp` in the same dialect is incomplete at the function declaration because ops classes are declared in alphabetical order. Alternatively, functions may be too big to be desired...

Many codegen pass require this pass with useful triple info. Legacy pass manager need to
add a TargetLibraryInfo with the module info before run passes. Or the TargetLibraryInfo
will be initialized too conservative.

Reviewed By: pengfei, aeubanks

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

CMake may add /Debug in the CONFIG-specific flag.

Reviewed By: rnk

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

The async data movement can cause data race if the target supports it.
Details can be found in [1]. This patch tries to fix this problem by attaching
an event to the entry of data mapping table. Here are the details.

For each issued data movement, a new event is generated and returned to `libomptarget`
by calling `createEvent`. The event will be attached to the corresponding mapping table
entry.

For each data mapping lookup, if there is no need for a data movement, the
attached event has to be inserted into the queue to gaurantee that all following
operations in the queue can only be executed if the event is fulfilled.

This design is to avoid synchronization on host side.

Note that we are using CUDA terminolofy here. Similar mechanism is assumped to
be supported by another targets. Even if the target doesn't support it, it can
be easily implemented in the following fall back way:
- `Event` can be any kind of flag that has at least two status, 0 and 1.
- `waitEvent` can directly busy loop if `Event` is still 0.

My local test shows that `bug49334.cpp` can pass.

Reference:
[1] https://bugs.llvm.org/show_bug.cgi?id=49940

Reviewed By: grokos, JonChesterfield, ye-luo

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

This change makes it possible to extract iOS-to-another-platform version mappings from `VersionMap` in the `SDKSettings.json` file in Darwin SDKs, for example, `iOS_watchOS` and `iOS_tvOS`.

This code was originally authored by Alex Lorenz.

rdar://81491680

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

Better capturing of invariants

Reviewed By: aartbik

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

These parameters aren't modified, so we make that invariant explicit.

Reviewed By: aartbik

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

This patch adds a couple of NewPM function passes (dot-dom and
dot-dom-only) that dump DomTree into .dot files.

Reviewed-By: aeubanks
Differential Revision: https://reviews.llvm.org/D116629

- Recognize older checks that might not end with Check.cpp
- Update list of checks based on improvements to add_new_check
- Fix spelling error in TransformerClangTidyCheck.h

Fixes #52962

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

This allows DFSan to find tainted values used to control program behavior.

Reviewed By: morehouse

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

Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.GetSingularLanguage. Now that this is no longer the case,
we need a way to specify a selected/preferred REPL language. This patch
does that with the help of a debugger property, taking inspiration from
how we store the scripting language.

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

Lower select(I1,Q,Q) by converting vector predicate Q to vector register V,
doing select(I1,V,V), and then converting the resulting V back to Q. Also,
try to avoid creating such situations in the first place.

This patch delayed the updates of the dominator tree to the very end of
the pass instead of doing that in small increments after each basic
block.

This improves the runtime of the pass in particular in pathological
cases because now the updater sees the full extend of the updates and
can decide whether it is faster to apply the changes incrementally or
just recompute the full tree from scratch.

Put differently, thanks to this patch, we can take advantage of the
improvements that Chijun Sima <simachijun@gmail.com> made in the
dominator tree updater a while ago with commit 32fd196c: "Teach the
DominatorTree fallback to recalculation when applying updates to speedup
JT (PR37929)".

This change is NFC but can improve the runtime of the compiler
dramatically in some pathological cases (where the pass was pushing a
lot (several thousands) of small updates (less than 6)).

For instance on the motivating example we went from 300+ sec to less
than a second.

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

This patch updated HexagonInstrInfo API to deal with missing immediate
memop instructions that checks for the validity of the offset.

Add support for Return Oriented Programming (ROP) protection for 32 bit.
This patch also adds a testing for AIX on both 64 and 32 bit.

Reviewed By: amyk

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

When enabling MSAN eager mode with noundef analysis these variables were found to not be initialized in unit tests.

Reviewed By: vitalybuka

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

Clang searches for runtimes (e.g. libclang_rt*) first in a
subdirectory named for the target triple (corresponding to
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON), then if it's not found uses
.../lib/<os>/libclang_rt* with a suffix corresponding to the arch and
environment name.

Android triples optionally include an API level indicating the minimum
Android version to be run on
(e.g. aarch64-unknown-linux-android21). When compiler-rt is built with
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON this API level is part of the
output path.

Linking code built for a later API level against a runtime built for
an earlier one is safe. In projects with several API level targets
this is desireable to avoid re-building the same runtimes many
times. This is difficult with the current runtime search method: if
the API levels don't exactly match Clang gives up on the per-target
runtime directory path.

To enable this more simply, this change tries target triple without
the API level before falling back on the old layout.

Another option would be to try every API level in the triple,
e.g. check aarch-64-unknown-linux-android21, then ...20, then ...19,
etc.

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

Instead of failing when it encounters a reference to an unknown symbol, Symbol DCE should ignore them. References to unknown symbols do not affect the overall function of Symbol DCE, so it should not need to fail when it encounters one.

In general, requiring that symbol references always be valid rather than only when necessary can be overly conservative.

Reviewed By: rriddle

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

opcodes, NFC.

NFC part of D115955.

These instructions have nothing to do with the new MOP CPY instructions,
and are better named DUP to avoid confusion.

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

[NFC][SimplifyCFG] Extract `performBlockTailMerging()` out of `tailMergeBlocksWithSimilarFunctionTerminators()`

This just adds feature declarations and some boilerplate.

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