Summary:
  This patch adds yaml2obj supporting for the auxiliary
  file header of XCOFF.

Reviewed By: DiggerLin, jhenderson

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

This reverts commit 81081dae.

This is a fix for test failures on expensive checks build caused by db289340.

With LLVM_ENABLE_EXPENSIVE_CHECKS enabled the llvm::sort shuffles the given container.
However, the sort is only called when the TTI is passed to replaceCongruentIVs.
In the mentioned patch we pass it TTI, so the sort happens. But due to shuffling
equivalent Phis may appear in different order from run to run.
With the stable_sort instead of sort this is impossible - the order of sorted Phis
is preserved.

Rewrite function signatures and calls to functions that accept or return
COMPLEX values.

Also teach insert_value and extract_value about the MLIR ComplexType, by
adding AnyComplex to AnyCompositeLike.

This patch is part of the effort for upstreaming the fir-dev branch.

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Tim Keith <tkeith@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

This fixes an assertion failure with -early-live-intervals when trying
to update the live intervals for a debug instruction, which don't even
have slot indexes.

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

This patch factors out division representation computation from upper-lower bound
inequalities to a separate function. This is done to improve readability and reuse.

This patch is marked NFC since the only change is factoring out existing code
to a separate function.

Reviewed By: grosser

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

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

Clang builtin utility `__remove_address_space` now works if generic
address space is not supported in C++ for OpenCL 2021.

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

This patch adds the basic infrastructure for the TargetRewrite pass,
which rewrites certain FIR dialect operations into target specific
forms. In particular, it converts boxchar function parameters, call
arguments and return values. Other convertions will be included in
future patches.

This patch is part of the effort for upstreaming the fir-dev branch.

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Tim Keith <tkeith@nvidia.com>

This reverts commit 81a7cad2.

The existing CGOpenMPRuntimeAMDGCN and CGOpenMPRuntimeNVPTX classes are
just code bloat. By removing them, the codebase gets a bit cleaner.

Reviewed By: jdoerfert, JonChesterfield, tianshilei1992

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

operand bundle "clang.arc.attachedcall" with ObjC runtime functions

The existing code only handles the case where the intrinsic being
rewritten is used as the called function pointer of a call/invoke.

I don't know if removing "if (!start_routine_)" from ThreadStart
is NFC.

This reverts commit b3267bb3.

Add module level inliner, which is a minimum viable product at this point.
Also add some tests for it.

RFC: https://lists.llvm.org/pipermail/llvm-dev/2021-August/152297.html

Reviewed By: kazu

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

https://reviews.llvm.org/D92808 made clang use the operand bundle
instead of emitting retainRV/claimRV calls on arm64. This commit makes
changes to clang that are needed to use the operand bundle on x86-64.

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

that don't use the inline asm marker

This patch makes the changes to the ARC middle-end passes that are
needed to handle operand bundle "clang.arc.attachedcall" on targets that
don't use the inline asm marker for the retainRV/autoreleaseRV
handshake (e.g., x86-64).

Note that anyone who wants to use the operand bundle on their target has
to teach their backend to handle the operand bundle. The x86-64 backend
already knows about the operand bundle (see
https://reviews.llvm.org/D94597).

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

Change-Id: Ic83ff1ec86d6a7d61b07fa3df7e0cb2790b5ebc7

This predates the templated variant, and has been simply forwarding
to getSplatValue<Attribute> for some time. Removing this makes the
API a bit more uniform, and also helps prevent users from thinking
it is "cheap".

Tablegen uses copious amounts of global state for uniquing various records.
This was fine under the original vision where tablegen was a tool, and not a
library, but there are various usages of tablegen that want to use it as a library.
One concrete example is that downstream we have a kythe indexer for tablegen
constructs that allows for IDEs to serve go-to-definition/references/and more.
We currently (kind of hackily) keep the tablegen parts in a shared library that
gets loaded/unloaded.

This revision starts to remedy this by globbing all of the static state into a
managed static so that they can at least be unloaded with llvm_shutdown.
A better solution would be to feed in a context variable (much like how
the IR in LLVM/MLIR do), but that is a more invasive change that can come later.

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

When emitting a reloc for the Wasm global __stack_pointer, it was inadvertedly added to the symbols used for generating aranges, which caused some aranges to use it as the end symbol in a symbol diff, which caused a reloc for it to be emitted, which then caused an assert in `wasm64` since we have no 64-bit relocs for Wasm globals.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=52376
Differential Revision: https://reviews.llvm.org/D113438

A new tool that compares TargetLibraryInfo's opinion of the availability
of library function calls against the functions actually exported by a
specified set of libraries. Can be helpful in verifying the correctness
of TLI for a given target, and avoid mishaps such as had to be addressed
in D107509 and 94b4598d.

The tool currently supports ELF object files only, although it's unlikely
to be hard to add support for other formats.

Re-commits 62dd4881 with changes to use pre-generated objects, as not all
bots have ld.lld available.

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

There are several aspects of the API that either aren't easy to use, or are
deceptively easy to do the wrong thing. The main change of this commit
is to remove all of the `getValue<T>`/`getFlatValue<T>` from ElementsAttr
and instead provide operator[] methods on the ranges returned by
`getValues<T>`. This provides a much more convenient API for the value
ranges. It also removes the easy-to-be-inefficient nature of
getValue/getFlatValue, which under the hood would construct a new range for
the type `T`. Constructing a range is not necessarily cheap in all cases, and
could lead to very poor performance if used within a loop; i.e. if you were to
naively write something like:

```
DenseElementsAttr attr = ...;
for (int i = 0; i < size; ++i) {
  // We are internally rebuilding the APFloat value range on each iteration!!
  APFloat it = attr.getFlatValue<APFloat>(i);
}
```

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

Fixes: https://bugs.llvm.org/show_bug.cgi?id=52352
Differential Revision: https://reviews.llvm.org/D113230

Not all bots have ld.lld available.
This reverts commit 62dd4881.

This resulted in the final argument being dropped from the output, which
can be rather important.

The outdated documentation diverges a lot from the current state of
COFF/Mach-O/ELF/wasm ports and may just confuse users. It is better rewriting
some if useful.

Tested with `ninja docs-lld-html`

Reviewed By: #lld-macho, lhames, Jez Ng

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

Add a new directive `either` to specify the operands can be matched in either order

Reviewed By: jpienaar, Mogball

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

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

This is consistent with what we do for other operands that are required
to be constants.

I don't think this results in any real changes. The pattern match
code for isel treats ConstantSDNode and TargetConstantSDNode the same.