Lefover from review for https://reviews.llvm.org/D126509#inline-1218795

As there 3 intercepts that depend on libresolv, link tests in ./configure scripts may be confuse by the presence of resolv symbols (i.e. dn_expand) even with -lresolv and get a runtime error.

Android provides the functionality in libc.

https://reviews.llvm.org/D122849
https://reviews.llvm.org/D126851

Reviewed By: eugenis, MaskRay

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

Transpose operations on constant data were getting folded during the
canonicalization process. This has compile time cost proportional to
the constant size. Moving this to a separate pass to enable optionality
and flexibility of how such scenarios can be handled.

Reviewed By: rsuderman, jpienaar, stellaraccident

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

Our rules to determine if the throw expression are within the variable
scope were giving a false negative result in case the throw expression
would appear within a decltype in a nested function declaration.

Per P2266R3, the relevant rule is: [expr.prim.id.unqual]/2
```
    if the id-expression (possibly parenthesized) is the operand of a throw-expression, and names an implicitly movable entity that belongs to a scope that does not contain the compound-statement of the innermost lambda-expression, try-block , or function-try-block (if any) whose compound-statement or ctor-initializer encloses the throw-expression.
```

This fixes PR54341.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

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

This reverts commit 99a83b12.

This reverts commit 60798044.

BasicTTI needs to return an invalid cost for scalable vectors instead of crash.  Without this, it is impossible to write tests for missing functionality in a target.

Summary: Emscripten now handles/supports this new mode.

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, cfe-commits

Tags: #clang

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

Currently, only custom sections can be selected by operations that use section
names, because only custom sections have explicit names (whereas known sections
have names defined by the spec and only use their indices in the binary format).
This CL makes objdopy use the spec-defined names for these sections, allowing
them to be used in operations such as dumping and removal.

This is a prerequisite for fixing
https://github.com/emscripten-core/emscripten/issues/13084

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

For consistency with other parts of code.

Approved by efriedma in differential revision
https://reviews.llvm.org/D127055

Adds supprot for vector unroll transformations to unroll in different
orders. For example, the `vector.contract` can be unrolled into a
smaller set of contractions.  There is a choice of how to unroll the
decomposition  based on the traversal order of (dim0, dim1, dim2).
The choice of traversal order can now be specified by a callback which
given by the caller of the transform. For now, only the
`vector.contract`, `vector.transfer_read/transfer_write` operations
support the callback.

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

Reviewed By: Mordante, var-const, #libc

Spies: libcxx-commits, mgorny

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

The relevant runtime libraries have been updated to support this
now.

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

Switching this target to WinEH also seems to affect the `-windows-itanium`
target.

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

This fixes unwinding in boundary cases on ARM with SEH.

In the case of ARM/Thumb, disp->ControlPc points at the following
instruction, with the thumb bit set. Thus by decrementing 1,
it still points at the next instruction. To achieve the desired
effect of pointing at the previous instruction, one first has to strip
out the thumb bit, then do the decrement by 1 to reach the previous
instruction.

When libcxxabi looks for call site ranges, it already does
`_Unwind_GetIP(context) - 1` (in `scan_eh_tab` in
libcxxabi/src/cxa_personality.cpp), so we shouldn't do the
corresponding `- 1` multiple times.

In the case of libcxxabi on Thumb, `funcStart` (still in `scan_eh_tab`)
may have the thumb bit set. If the program counter address is
decremented both in libunwind (first removing the thumb bit, then
decremented), and then libcxxabi decrements it further, and compares
with a `funcStart` with the thumb bit set, it could point to one byte
before the start...

There's no such corresponding code for ARM64 (which has been working
in production for years). The SEH version of the Unwind functions
(e.g. `_Unwind_GetLanguageSpecificData`) doesn't use these fields.

The `_Unwind_ForcedUnwind` function would need these bits though,
but that's not used in normal C++ exception unwinding.

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

Check `__SEH__` when checking if ARM EHABI should be implied,
similarly to 4a3722a2 / D126866.

Fix a warning by using the right format specifier (PRIxPTR instead
of PRIx64), and add a double->float cast in a codepath that hasn't
been built so far.

This is enough to make SEH unwinding of itanium ABI exceptions on
ARM mostly work - one specific issue is fixed in a separate follow-up
patch.

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

ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.

As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.

This is the same change as 4a3722a2 /
D126866, applied on the compiler-rt builtins gcc_personality_v0
function.

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

ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.

As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.

This is the same change as 4a3722a2 /
D126866, applied on the clang headers.

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

ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.

As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.

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

In MinGW environments, thanks to slightly different code generation
and linker tricks, it's possible to link against a DLL C++ standard
library without dllimport attributes.

This allows using one single set of headers for linking against
either the DLL or a static library, leaving the decision entirely
up to the linking stage (where it can be switched with options like
-static-libstdc++).

This matches how libstdc++ headers work; there's no dllimport attributes
by default (unless the user has defined _GLIBCXX_DLL when including
headers).

This allows using one single set of headers while linking against
either a DLL or a static library, just like on Unix platforms.

This matches how libc++ has been used in MinGW configurations for
years (by first building the DLL, then configuring a static-only
build and installing on top, overwriting the libc++ config file
with one for static linking) by multiple MinGW toolchains, making
the dllimport-less use the de-facto tested configuration in the wild.

This also allows building all of libc++ in one single CMake
configuration, instead of having to do two separate builds on top of
each other.

(Linking against a DLL without dllimport can break if e.g. templates
use inconsistent visibility attributes - in cases where it still
works when using explicit dllimport; such a case was fixed in
948dd664 / D99932. With this as the
default configuration, we can catch such issues in CI.)

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

In clang-cl/MSVC environments, linking against a DLL C++ standard
library requires having dllimport attributes in the headers; this
has been used for detecting whether the tests link against a DLL,
by looking at the libc++ specific define
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS.

In mingw environments, thanks to slightly different code generation
and a couple linker tricks, it's possible to link against a DLL C++
standard library without dllimport attributes. Therefore, don't
rely on the libc++ specific header define for the detection.

Replace the detection with a runtime test.

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

This commit beefs up the documentation for MLIR language servers by
adding proper documentations/examples/etc for the provided PDLL
language server capabilities. Given that this documentation is also used
for the vscode extension, this commit also updates the user facing vscode
extension documentation.

Not that the images referenced in the new documentation are hosted on
the website, and will be commited to mlir-www shortly after this commit
lands.

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

At the end of the codegen pipeline for DXIL we will emit the DXIL into
a global variable in the Module annotated for the "DXIL" section.

This will be used by the MCDXContainerStreamer to emit the DXIL into a
DXContainer DXIL part.

Other parts of the DXContainer will be constructed similarly by
serializing their values into GlobalVariables.

This will allow DXIL to flow into DXContainers through the normal
MCStreamer flow used in the MC layer.

Depends on D122270

Reviewed By: kuhar

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

Summary:

Issue 55761:
Change the lit test for print-changed=dot-cfg to have a regular expression
for the template arguments portion of the name for a pass manager pass.
This part of the name can change because it is based on the name provided
by the compiler, which is implementation-dependent. This mimics the
other change printer tests.

Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: mgorny (Michal Gorny)
Differential Revision: https://reviews.llvm.org/D126876

Fixes a bug of us not correctly updating the terminator of the loop's
preheader, if multiple terminating branch instructions are present.

This is tested through existing tests. The bug itself is hard or not
possible to get exposed with the upstream Hexagon backend, because
the machine pipeliner checks for an existing preheader, which is
defined as a block with only 1 edge into the header.

The condition of this bug is a block into the loop with more than 1
edge, and not every downstream target checks for an existing preheader.

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

DebugTypeVisitor

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

This operation should be supported as a named op because
when the operands are viewed as having canonical layouts
with decreasing strides, then the "reduction" dimensions
of the filter (h, w, and c) are contiguous relative to each
output channel. When lowered to a matrix multiplication,
this layout is the simplest to deal with, and thus future
transforms/vectorizations of `conv2d` may find using this
named op convenient.

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

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

Current BTF only supports 32-bit value. For example,
  enum T { VAL = 0xffffFFFF00000008 };
the generated BTF looks like
        .long   16                              # BTF_KIND_ENUM(id = 4)
        .long   100663297                       # 0x6000001
        .long   8
        .long   18
        .long   8
The encoded value is 8 which equals to (uint32_t)0xffffFFFF00000008
and this is incorrect.

This patch introduced BTF_KIND_ENUM64 which permits to encode
64-bit value. The format for each enumerator looks like:
        .long   name_offset
        .long   (uint32_t)value # lower-32 bit value
        .long   value >> 32     # high-32 bit value

We use two 32-bit values to represent a 64-bit value as current
BTF type subsection has 4-byte alignment and gaps are not permitted
in the subsection.

This patch also added support for kflag (the bit 31 of CommonType.Info)
such that kflag = 1 implies the value is signed and kflag = 0
implies the value is unsigned. The kernel ...

This change finishes fleshing out the ObjectYAML tools to support
converting DXContainer files into yaml representations.

Depends on D124944

Reviewed By: lhames

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

Patch adds new GICombineRules for G_ADD:

G_ADD(x, G_SUB(y, x)) -> y
G_ADD(G_SUB(y, x), x) -> y

Patch additionally adds new combine tests for AArch64 target for
these new rules.

Reviewed by: paquette

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