Instead of hardcoding all of the register name strings.

This marks delayed-definition-die-searching.test as unsupported on
Windows. Clang uses link.exe as default linker if not marked explicitly
to use lld. When used with link.exe clang produces PDB format debug info
even when -gdwarf is specified.
This test will be unsupported until we make lldb-aarch64-windows buildbot
to use lld.

This reapplies
https://github.com/llvm/llvm-project/commit/195d8ac26d91ca798733c3a5f58d67992d43503d
[DirectX] Fix DXIL part header version encoding. The endian issue was
fixed by
https://github.com/llvm/llvm-project/commit/f42117c8517cc928c6373bad35ebf75d94fe865b.

Move MinorVersion be the lower 8 bit.
Set DXIL version in DXContainerObjectWriter::writeObject.

Fixes #89952

This fixes the new test linkerscript/enable-non-contiguous-regions.test
from #90007 in -stdlib=libc++ -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG builds.

adjustOutputSections does not discard the output section .potential_a
because it contained .a (which would be spilled to .actual_a).
.potential_a and .bc have the same address and will cause an assertion
failure.

Windows build of `mlir` with Visual Studio (19.36.32538 for x64) using
with the following command:

`cmake.exe -GNinja -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_PROJECTS=mlir -DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_RTTI=1
-DLLVM_TARGETS_TO_BUILD=host ../llvm`

is leading to a crash when calling canonicalization on
`tensor.pack`/`tensor.unpack` ops `mlir-opt --canonicalize input.mlir`
where the `input.mlir` is as follows (this is taken from one of the
filecheck tests for `tensor.pack`):

```
func.func @pack_unpack(%arg0: tensor<128x256xf32>) -> tensor<128x256xf32> {
          %pack_dest = tensor.empty() : tensor<8x16x8x32xf32>
          %unpack_dest = tensor.empty() : tensor<128x256xf32>
          %tp = tensor.pack %arg0 outer_dims_perm = [1, 0] inner_dims_pos = [0, 1] inner_tiles = [8, 32] into %pack_dest : tensor<128x256xf32> -> tensor<8x16x8x32xf32>
          %tup = tensor.unpack %tp outer_dims_perm = [1, 0] inner_dims_pos = [0, 1] inner_tiles = [8, 32] into %unpack_dest : tensor<8x16x8x32xf32> -> tensor<128x256xf32>
          return %tup : tensor<128x256xf32>
        }
```

The crash is seemingly coming from invalid memory access during
iterating over `innerDimsPos` within `getPackOpResultTypeShape`.

This crash is also causing the following tests to fail:


```
MLIR :: Dialect/Linalg/canonicalize.mlir                                                                                                                    
MLIR :: Dialect/Linalg/data-layout-propagation.mlir                                                                                                         
MLIR :: Dialect/Linalg/generalize-tensor-pack-tile.mlir                                                                                                     
MLIR :: Dialect/Linalg/generalize-tensor-pack.mlir                                                                                                          
MLIR :: Dialect/Linalg/generalize-tensor-unpack-tile.mlir                                                                                                   
MLIR :: Dialect/Linalg/generalize-tensor-unpack.mlir                                                                                                        
MLIR :: Dialect/Linalg/transform-lower-pack.mlir                                                                                                            
MLIR :: Dialect/Linalg/transform-op-fuse.mlir                                                                                                               
MLIR :: Dialect/Linalg/transform-op-pack.mlir                                                                                                               
MLIR :: Dialect/Linalg/transform-pack-greedily.mlir                                                                                                         
MLIR :: Dialect/Tensor/canonicalize.mlir                                                                                                                   
MLIR :: Dialect/Tensor/fold-into-pack-and-unpack.mlir                                                                                                       
MLIR :: Dialect/Tensor/invalid.mlir                                                                                                                         
MLIR :: Dialect/Tensor/ops.mlir                                                                                                                             
MLIR :: Dialect/Tensor/simplify-pack-unpack.mlir                                                                                                           
MLIR :: Dialect/Tensor/tiling.mlir
```

## Why
Currently, the system header `errno.h` is included in `libc_errno.h`,
which is supposed to be consumed by internal implementations only. As
unit and hermetic tests should never use `#include <errno.h>` but
instead use `#include "src/errno/libc_errno.h"`, we do not want to
implicitly include `errno.h`. In order to have a clear seperation
between those two, we want to pull out the definitions of errno numbers
from `errno.h`.

## What
* Extract the definitions of errno numbers from
[include/errno.h.def](https://github.com/llvm/llvm-project/pull/91150/files#diff-ed38ed463ed50571b498a5b69039cab58dc9d145da7f751a24da9d77f07781cd)
and place it under
[include/llvm-libc-macros/linux/error-number-macros.h](https://github.com/llvm/llvm-project/pull/91150/files#diff-d6192866629690ebb7cefa1f0a90b6675073e9642f3279df08a04dcdb05fd892)
* Provide mips-specific errno numbers in
[include/llvm-libc-macros/linux/mips/error-number-macros.h](https://github.com/llvm/llvm-project/pull/91150/files#diff-3fd35a4c94e0cc359933e497b10311d857857b2e173e8afebc421b04b7527743)
* Find definition of mips errno numbers in glibc
[here](https://github.com/bminor/glibc/blob/ea73eb5f581ef5931fd67005aa0c526ba43366c9/sysdeps/unix/sysv/linux/mips/bits/errno.h#L32-L50)
(equally defined in the Linux kernel)
* Provide sparc-specific errno numbers in
[include/llvm-libc-macros/linux/sparc/error-number-macros.h](https://github.com/llvm/llvm-project/pull/91150/files#diff-5f16ffb2a51a6f72ebd4403aca7e1edea48289c99dd5978a1c84385bec4f226b)
* Find definition of sparc errno numbers in glibc
[here](https://github.com/bminor/glibc/blob/ea73eb5f581ef5931fd67005aa0c526ba43366c9/sysdeps/unix/sysv/linux/sparc/bits/errno.h#L33-L51)
(equally defined in the Linux kernel)
* Include proxy header `errno_macros.h` instead of the system header
`errno.h` in `libc_errno.h`/`libc_errno.cpp`

Closes https://github.com/llvm/llvm-project/issues/80172

There is nothing specific here and it is not different from i16 or f16.

Switch from FuncBranchData intermediate maps (Intra/InterIndex)
to aggregated Data, same as one used by DataReader:
https://github.com/llvm/llvm-project/blob/e62ce1f8842cca36eb14126d79dcca0a85bf6d36/bolt/lib/Profile/DataReader.cpp#L385-L389
This aligns the order of the output between YAMLProfileWriter and
writeBATYAML.

Test Plan: updated bolt-address-translation-yaml.test

Reviewers: rafaelauler, dcci, ayermolo, maksfb

Reviewed By: ayermolo, maksfb

Pull Request: https://github.com/llvm/llvm-project/pull/91289

This is a proof of concept recognition of the most basic forms of ReLu
operations, used to show-case sparsification of end-to-end PyTorch
models. In the long run, we must avoid lowering such constructs too
early (with this need for raising them back).

See discussion at

https://discourse.llvm.org/t/min-max-abs-relu-recognition-starter-project/78918

The testing we have for vector ptradd was a bit lacking. In adding tests
this patch found a couple of issues mostly with the way v3 vectors of
ptrs were sometimes legalized via i64, and with non-i64 additions. It
does not attempt to fix the issue with mergevalues from returning vector
ptrs.

The vector callee saved registers shouldn't affect the frame pointer
offset so we don't want to consider them.

I've listed the GPR, FPR32, and FPR64 register classes explicitly
because getMinimalPhysRegClass is slow and this function is called
frequently. So explicitly listing the interesting classs should be
a compile time improvement.

[RISCV] Don't exlude the frame pointer from the callee saved registers in RISCVRegisterInfo::needsFrameBaseReg.

Instead of using getReservedRegs, just check the subtarget reserved
list. getReservedRegs considers the frame pointer to be reserved when
it is being used, but we do need to save/restore it so it should be
counted as a callee saved register. AArch64 hardcodes their callee
saved size, but the comment mentions the Frame Pointer being counted.

This avoids 'Permission denied' when PWD is read-only.
While here, change the triple from a Linux one to a generic ELF one.

This is continuation of efforts to split `Sema` up, following the
example of OpenMP, OpenACC, etc. Context can be found in
https://github.com/llvm/llvm-project/pull/82217 and
https://github.com/llvm/llvm-project/pull/84184.

I split formatting changes into a separate commit to help reviewing the
actual changes.

This is the second attempt at merging #91800, which bounced due to a
linker error apparently caused by an undeclared dependency.
`MLIRVectorToSPIRV` needed to depend on `MLIRVectorTransforms`. In fact
that was a preexisting issue already flagged by the tool in
https://discourse.llvm.org/t/ninja-can-now-check-for-missing-cmake-dependencies-on-generated-files/74344.

Context: https://github.com/iree-org/iree/issues/17346.

Test IREE integrate showing it's fixing the problem it's intended to
fix, i.e. it allows IREE to drop its local revert of
https://github.com/llvm/llvm-project/pull/89131:

https://github.com/iree-org/iree/pull/17359

This is added to VectorToSPIRV because SPIRV doesn't currently handle
`vector.interleave` (see motivating context above).

This is limited to 1D, non-scalable vectors.

If you change the generation script and re-run ninja (or whatever drives
your build), it currently will not regenerate SBLanguages.h. With
dependency tracking, it should re-run when the script changes.

Offset annotation was missed when optimizing an unconditional branch to
a tail call.

Test Plan: update bb-with-two-tail-calls.s

This commit allows `inferFragType` to see through all arith.ext op
and other elementwise users before reaching contract op for
figuring out the fragment type.

Add a new clang-tidy check that converts absl::StrFormat (and similar
functions) to std::format (and similar functions.)

Split the configuration of FormatStringConverter out to a separate
Configuration class so that we don't risk confusion by passing two
boolean configuration parameters into the constructor. Add
AllowTrailingNewlineRemoval option since we never want to remove
trailing newlines in this check.

Ignore optionals in unevaluated context, like static_assert or decltype.

Closes #89593

Co-authored-by: Leon Clark <leoclark@amd.com>

We emit `ASTContext` and `TypeSystem` pointers into the `expr` log but
there is no easy way (that I know of) to correlate the pointer value
back to an easily readible form. This patch simply logs the name of the
`TypeSystem` and the associated `ASTContext` into the `expr` channel
whenever we create a new `TypeSystemClang`.

The following is an example of the new log entries:
```
$ grep Created /tmp/lldb.log 
 Created new TypeSystem for (ASTContext*)0x0000000101a2e200 'ASTContext for '/Users/michaelbuch/a.out''
 Created new TypeSystem for (ASTContext*)0x0000000102512a00 'scratch ASTContext'
 Created new TypeSystem for (ASTContext*)0x0000000102116a00 'ClangModulesDeclVendor ASTContext'
 Created new TypeSystem for (ASTContext*)0x00000001022e8c00 'Expression ASTContext for '<user expression 0>''
 Created new TypeSystem for (ASTContext*)0x00000001103e7200 'AppleObjCTypeEncodingParser ASTContext'
 Created new TypeSystem for (ASTContext*)0x00000001103f7000 'AppleObjCDeclVendor AST'
 Created new TypeSystem for (ASTContext*)0x00000001104bfe00 'Expression ASTContext for '<clang expression>''
 Created new TypeSystem for (ASTContext*)0x0000000101f01000 'Expression ASTContext for '<clang expression>''
 Created new TypeSystem for (ASTContext*)0x00000001025d3c00 'Expression ASTContext for '<clang expression>''
 Created new TypeSystem for (ASTContext*)0x0000000110422400 'Expression ASTContext for '<clang expression>''
 Created new TypeSystem for (ASTContext*)0x000000011602c200 'Expression ASTContext for '<user expression 1>''
 Created new TypeSystem for (ASTContext*)0x0000000110641600 'Expression ASTContext for '<clang expression>''
 Created new TypeSystem for (ASTContext*)0x0000000110617400 'Expression ASTContext for '<clang expression>''
```

When enabled, input sections that would otherwise overflow a memory
region are instead spilled to the next matching output section.

This feature parallels the one in GNU LD, but there are some differences
from its documented behavior:

- /DISCARD/ only matches previously-unmatched sections (i.e., the flag
does not affect it).

- If a section fails to fit at any of its matches, the link fails
instead of discarding the section.

- The flag --enable-non-contiguous-regions-warnings is not implemented,
as it exists to warn about such occurrences.

The implementation places stubs at possible spill locations, and
replaces them with the original input section when effecting spills.
Spilling decisions occur after address assignment. Sections are spilled
in reverse order of assignment, with each spill naively decreasing the
size of the affected memory regions. This continues until the memory
regions are brought back under size. Spilling anything caus...

It's already added in isFrameOffsetLegal so adding it in needsFrameBaseReg
causes it to be double counted.

The test we had didn't match it's description.

Now we have one test with a large offset that requires a virtual base register
and a test with a smaller offset that should not.

There is currently a bug that causes the offset to double counted
leading to the small case also using a virtual base register.

This patch calculates knownbits from fp instructions/dominating fcmp
conditions. It will enable more optimizations with signbit idioms.

Revert "[mlir][vector] Add Vector-dialect interleave-to-shuffle pattern, enable in VectorToSPIRV" (#92006)

Reverts llvm/llvm-project#91800

Reason: https://lab.llvm.org/buildbot/#/builders/268/builds/13935

With blocking issues fixed, re-enable relaxed template template argument
matching by reverting these commits.

This reverts commit 4198aebc.
This reverts commit 2d5634a4.

This ensures that we log pointers as lower-case hex. E.g., instead of:
```
 LayoutRecordType on (ASTContext*)0x000000010E78D600 'scratch ASTContext' for (RecordDecl*)0x000000010E797
```
we now log:
```
 LayoutRecordType on (ASTContext*)0x000000010e78d600 'scratch ASTContext' for (RecordDecl*)0x000000010e797
```

Which is consistent with how the AST dump gets emitted into the log.
This makes it easier to correlate pointers we log from LLDB and pointers
that are part of any AST dumps in the same `expr` log.

Reverts llvm/llvm-project#90007

Broke in merging I think.

When enabled, input sections that would otherwise overflow a memory
region are instead spilled to the next matching output section.

This feature parallels the one in GNU LD, but there are some differences
from its documented behavior:

- /DISCARD/ only matches previously-unmatched sections (i.e., the flag
does not affect it).

- If a section fails to fit at any of its matches, the link fails
instead of discarding the section.

- The flag --enable-non-contiguous-regions-warnings is not implemented,
as it exists to warn about such occurrences.

The implementation places stubs at possible spill locations, and
replaces them with the original input section when effecting spills.
Spilling decisions occur after address assignment. Sections are spilled
in reverse order of assignment, with each spill naively decreasing the
size of the affected memory regions. This continues until the memory
regions are brought back under size. Spilling anything causes another
pass of address assignment, and this continues to fixed point.

Spilling after rather than during assignment allows the algorithm to
consider the size effects of unspillable input sections that appear
later in the assignment. Otherwise, such sections (e.g. thunks) may
force an overflow, even if spilling something earlier could have avoided
it.

A few notable feature interactions occur:

- Stubs affect alignment, ONLY_IF_RO, etc, broadly as if a copy of the
input section were actually placed there.

- SHF_MERGE synthetic sections use the spill list of their first
contained input section (the one that gives the section its name).

- ICF occurs oblivious to spill sections; spill lists for merged-away
sections become inert and are removed after assignment.

- SHF_LINK_ORDER and .ARM.exidx are ordered according to the final
section ordering, after all spilling has completed.

- INSERT BEFORE/AFTER and OVERWRITE_SECTIONS are explicitly disallowed.

device_type, also spelled as dtype, specifies the applicability of the
clauses following it, and takes a series of identifiers representing the
architectures it applies to.  As we don't have a source for the valid
architectures yet, this patch just accepts all.

Semantically, this also limits the list of clauses that can be applied
after the device_type, so this implements that as well.

This reverts commit 06f04b2e.
This reapplies commit c4a9a374.
The build failures were caused by the patch depending on the order of
evaluation of arguments to a function. This reapplication separates out
the capture of one of the values.

When partial ordering alias templates against template template
parameters, allow pack expansions when the alias has a fixed-size
parameter list.

These expansions were generally disallowed by proposed resolution for
CWG1430.

By previously diagnosing these when checking template template
parameters, we would be too strict in trying to prevent any potential
invalid use.

This flows against the more general idea that template template
parameters are weakly typed, that we would rather allow an argument that
might be possibly misused, and only diagnose the actual misuses during
instantiation.

Since this interaction between P0522R0 and CWG1430 is also a
backwards-compat breaking change, we implement provisional wording to
allow these.

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