Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update scripts where possible, and by
find + replace where not.

…spose(shape_cast) (llvm#100731)" (llvm#102457)

This reverts commit 88accd9.

This change can be dropped in favor of just llvm#102017.

Modifying `auto` to `auto&` to avoid unnecessary copying

…78112)

https://cplusplus.github.io/CWG/issues/2627.html

It is no longer a narrowing conversion when converting a bit-field to a
type smaller than the field's declared type if the bit-field has a width
small enough to fit in the target type. This includes integral
promotions (`long long i : 8` promoted to `int` is no longer narrowing,
allowing `c.i <=> c.i`) and list-initialization (`int n{ c.i };`)

Also applies back to C++11 as this is a defect report.

…lvm#102573)

Disables `vector.matrix_multiply` for scalable vectors. As per the docs:

>  This is the counterpart of llvm.matrix.multiply in MLIR

I'm not aware of any use of matrix-multiply intrinsics in the context of
scalable vectors, hence disabling.

…lir (llvm#102361)

…2535)

Commit cee594c added support to clang for multiple expressions in
`num_teams` clause. Add follow-up changes to flang.

As all the necessary information is encoded using attributes
nowadays, this test doesn't actually depend on the triple
anymore.

Syntacore SCR5 is an entry-level Linux-capable 32/64-bit RISC-V
processor core.
Overview: https://syntacore.com/products/scr5

Scheduling model will be added in a subsequent PR.

Co-authored-by: Dmitrii Petrov <dmitrii.petrov@syntacore.com>
Co-authored-by: Anton Afanasyev <anton.afanasyev@syntacore.com>

…lvm#96287)"

This reverts commit ccb2b01.

Causes buildbot failures, e.g. on ppc64le builders.

Follow up on 199d6f2 (LSV: document hang reported in llvm#37865) to fix the
build when omitting the AArch64 target. Add the missing lit.local.cfg.

We should handle allocator attributes not only on function
declarations, but also on the call-site. That way we can e.g.
also optimize cases where the allocator function is a virtual
function call.

This was already supported in some of the MemoryBuiltins helpers,
but not all of them. This adds support for allocsize, alloc-family
and allockind("free").

…perations. (llvm#102105)

The code-generator is currently not able to handle scalable vectors of
<vscale x 1 x eltty>. The usual "fix" for this until it is supported is
to mark the costs of loads/stores with an invalid cost, preventing the
vectorizer from vectorizing at those factors. But on rare occasions
loops do not contain load/stores, only reductions.

So whilst this is still unsupported return an invalid cost to avoid
selecting vscale x 1 VFs. The cost of a reduction is not currently used
by the vectorizer so this adds the cost to the add/mul/and/or/xor or
min/max that should feed the reduction. It includes reduction costs
too, for completeness. This change will be removed when code-generation
for these types is sufficiently reliable.

Fixes llvm#99760

If nobuiltin is set, directly return nullptr instead of using a
separate out parameter and having all callers check this.

This allows moving some tests relying on -stop-after=amdgpu-isel
to move to checking -stop-after=finalize-isel instead, which
will more reliably pass the verifier.

I forgot to update the version info in the SDKSettings file when I
updated it to the real version relevant to the test.

Add support in `-convert-gpu-to-llvm-spv` to convert `gpu.func` to
`llvm.func` operations.

- `spir_kernel`/`spir_func` calling conventions used for
kernels/functions.
- `workgroup` attributions encoded as additional `llvm.ptr<3>`
arguments.
- No attribute used to annotate kernels
- `reqd_work_group_size` attribute using to encode
`gpu.known_block_size`.
- `llvm.mlir.workgroup_attrib_size` used to encode workgroup attribution
sizes. This will be attached to the pointer argument workgroup
attributions lower to.

**Note**: A notable missing feature that will be addressed in a
follow-up PR is a `-use-bare-ptr-memref-call-conv` option to replace
MemRef arguments with bare pointers to the MemRef element types instead
of the current MemRef descriptor approach.

---------

Signed-off-by: Victor Perez <victor.perez@codeplay.com>

This PR adds conversion patterns for MemRef to the `convert-to-spirv`
pass, introduced in llvm#95942. Conversions from MemRef memory space to
SPIR-V storage class were also included, and would run before the final
dialect conversion phase.

**Future Plans**
- Add tests for ops other than `memref.load` and `memref.store`

---------

Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>

…llvm#102616)

There's no need for them to have different types.

Part of <llvm#62629>.

…#101407)

This patch adds the code generation support for multi-dim `num_teams`
clause when it is used with `target teams ompx_bare` construct.

…ack for `insertelement` (llvm#82130)

Prior to this patch, SelectionDAG generated aligned move onto stacks for
AVX registers when the function was marked as a no-realign-stack
function. This lead to misalignment between the stack and the
instruction generated. This patch fixes the issue. There was a similar
issue reported for `extractelement` which was fixed in
a6614ec

Co-authored-by: Manish Kausik H <hmamishkausik@gmail.com>

Make it possible to do things like the following, regardless of whether
the offload target is nvptx or amdgpu:

```
$ clang -O1 -g -fopenmp --offload-arch=native test.c                       \
    -Xoffload-linker -mllvm=-pass-remarks=inline                           \
    -Xoffload-linker -mllvm=-force-remove-attribute=g.internalized:noinline\
    -Xoffload-linker --lto-newpm-passes='forceattrs,default<O1>'           \
    -Xoffload-linker --lto-debug-pass-manager                              \
    -foffload-lto
```

To accomplish that:

- In clang-linker-wrapper, do not forward options via `-Wl` if they
might have literal commas. Use `-Xlinker` instead.
- In clang-nvlink-wrapper, accept `--lto-debug-pass-manager` and
`--lto-newpm-passes`.
- In clang-nvlink-wrapper, drop `-passes` because it's inconsistent with
the interface of `lld`, which is used instead of clang-nvlink-wrapper
when the target is amdgpu. Without this patch, `-passes` is passed to
`nvlink`, producing an error anyway.

---------

Co-authored-by: Joseph Huber <huberjn@outlook.com>

Without this, the doc string is put in a single line. These
scripts have multi-line docstrings, so this makes their --help
output look much nicer.

Otherwise, no behavior change.

Inspired by llvm#99418 (which hopefully we can replace this code with at some point)

…opeForCallOperatorInstantiationRAII (llvm#100766)

This PR addresses issues related to the handling of `init capture` with
parameter packs in Clang's
`LambdaScopeForCallOperatorInstantiationRAII`.

Previously, `addInstantiatedCapturesToScope` would add `init capture`
containing packs to the scope using the type of the `init capture` to
determine the expanded pack size. However, this approach resulted in a
pack size of 0 because `getType()->containsUnexpandedParameterPack()`
returns `false`. After extensive testing, it appears that the correct
pack size can only be inferred from `getInit`.

But `getInit` may reference parameters and `init capture` from an outer
lambda, as shown in the following example:

```cpp
auto L = [](auto... z) {
    return [... w = z](auto... y) {
        // ...
    };
};
```

To address this, `addInstantiatedCapturesToScope` in
`LambdaScopeForCallOperatorInstantiationRAII` should be called last.
Additionally, `addInstantiatedCapturesToScope` has been modified to only
add `init capture` to the scope. The previous implementation incorrectly
called `MakeInstantiatedLocalArgPack` for other non-init captures
containing packs, resulting in a pack size of 0.

### Impact

This patch affects scenarios where
`LambdaScopeForCallOperatorInstantiationRAII` is passed with
`ShouldAddDeclsFromParentScope = false`, preventing the correct addition
of the current lambda's `init capture` to the scope. There are two main
scenarios for `ShouldAddDeclsFromParentScope = false`:

1. **Constraints**: Sometimes constraints are instantiated in place
rather than delayed. In this case,
`LambdaScopeForCallOperatorInstantiationRAII` does not need to add `init
capture` to the scope.
2. **`noexcept` Expressions**: The expressions inside `noexcept` have
already been transformed, and the packs referenced within have been
expanded. Only `RebuildLambdaInfo` needs to add the expanded captures to
the scope, without requiring `addInstantiatedCapturesToScope` from
`LambdaScopeForCallOperatorInstantiationRAII`.

### Considerations

An alternative approach could involve adding a data structure within the
lambda to record the expanded size of the `init capture` pack. However,
this would increase the lambda's size and require extensive
modifications.

This PR is a prerequisite for implmenting
llvm#61426

Tracking a set containing every block and operation visited can become
very expensive and is unnecessary.

Co-authored-by: Will Dietz <w@wdtz.org>

llvm#101978)

Default attributes assigned to all functions according to the command
line parameters. Some functions might have their own attributes and we
need to set or remove attributes accordingly.
Tests are updated to test this scenarios too.

The work of ParseRegularReg() should remain to be parsing the register
as it was specified, and not to try translate it to anything else.

It's up to operand predicates to decide on what is and is not an
acceptable register for an operand, including considering its expected
register class, and for the rest of the AsmParser infrastructure to
handle it respectively from there on.

This transform op makes it possible to query attributes associated to IR
by means of the DLTI dialect.

The op takes both a `key` and a target `op` to perform the query at.
Facility functions automatically find the closest ancestor op which
defines the appropriate DLTI interface or has an attribute implementing
a DLTI interface. By default the lookup uses the data layout interfaces
of DLTI. If the optional `device` parameter is provided, the lookup
happens with respect to the interfaces for TargetSystemSpec and
TargetDeviceSpec.

This op uses new free-standing functions in the `dlti` namespace to not
only look up specifications via the `DataLayoutSpecOpInterface` and on
`ModuleOp`s but also on any ancestor op that has an appropriate DLTI
attribute.

…m#102553)

With opaque pointers, nothing directly uses the value type, so we can
mutate it if we want. This avoid doing a complicated RAUW dance.

…lvm#102584)

Move tests that exercise DropUnitDimFromElementwiseOps and
DropUnitDimsFromTransposeOp to a dedicated file.

While these patterns are collected under populateFlattenVectorTransferPatterns
(and are tested via -test-vector-transfer-flatten-patterns), they can actually
be tested without the xfer Ops, and hence the split.

Note, this is mostly just moving tests from one file to another. The only real
change is the removal of the following check-lines:

```mlir
//   CHECK-128B-NOT:   memref.collapse_shape
```

These were added specifically to check the "flattening" logic (which introduces
`memref.collapse_shape`). However, these tests were never meant to test that
logic (in fact, that's the reason I am moving them to a different file) and
hence are being removed as copy&paste errors.

I also removed the following TODO:

```mlir
/// TODO: Potential duplication with tests from:
///   * "vector-dropleadunitdim-transforms.mlir"
///   * "vector-transfer-drop-unit-dims-patterns.mlir"
```
I've checked what patterns are triggered in those test files and neither
DropUnitDimFromElementwiseOps nor DropUnitDimsFromTransposeOp does.

…101561)"

This reverts commit 8f21ff9.

Crashed CI builds

This generalizes MSan's Arm NEON vst support, to include the
lane-specific variants.

This also updates the test from
llvm#100645.

Co-authored-by: OverMighty <its.overmighty@gmail.com>

…m#102086)

Currently `AMDGPUAttributorPass` is registered in default optimizer
pipeline.
This will allow the pass to run in default pipeline as well as at
thinLTO post
link stage. However, it will not run in full LTO post link stage. This
patch
moves it to full LTO.

This ports a fix from memprof (llvm#98510), which has a shadow mapping that is similar to ASan (8 bytes of shadow memory per 64 bytes of app memory). This patch changes the allocator to dynamically choose a base address, as suggested by Vitaly for memprof. This simplifies ASan's #ifdef's and avoids potential conflict in the event that ASan were to switch to a dynamic shadow offset in the future [1].

[1] Since shadow memory is mapped before the allocator is mapped:
- dynamic shadow and fixed allocator (old memprof): could fail if
"unlucky" (e.g., https://lab.llvm.org/buildbot/#/builders/66/builds/1361/steps/17/logs/stdio)
- dynamic shadow and dynamic allocator (HWASan; current memprof): always works
- fixed shadow and fixed allocator (current ASan): always works, if
constants are carefully chosen
- fixed shadow and dynamic allocator (ASan with this patch): always works

When working on very busy systems, check-offload frequently fails many
tests with this diagnostic:

```
clang: error: cannot determine amdgcn architecture: /tmp/llvm/build/bin/amdgpu-arch: Child timed out: ; consider passing it via '-march'
```

This patch accepts the environment variable
`CLANG_TOOLCHAIN_PROGRAM_TIMEOUT` to set the timeout. It also increases
the timeout from 10 to 60 seconds.

1. Add MipsPat to optimize (andi (srl (truncate i64 $1), x), y) to (andi
(truncate (dsrl i64 $1, x)), y).
2. Add MipsPat to optimize (ext (truncate i64 $1), x, y) to (truncate
(dext i64 $1, x, y)).

The assembly result is the same as gcc.

Fixes llvm#42826

Initially, the LRU list stored all mapped entries with no distinction
between the committed (non-madvise()'d) entries and decommitted
(madvise()'d) entries. Now these two types of entries re separated into
two lists, allowing future cache logic to branch depending on whether or
not entries are committed or decommitted. Furthermore, the retrieval
algorithm will prioritize committed entries over decommitted entries.
Specifically, committed entries that satisfy the MaxUnusedCachePages
requirement are retrieved before optimal-fit, decommitted entries.

This commit addresses the compiler errors raised
[here](llvm#100818 (comment)).

llvm-objdump -S issues unnecessary warnings for RISC-V relocatable files
containing .debug_loclists or .debug_rnglists sections with ULEB128
relocations. This occurred because `DWARFObjInMemory` verifies support for all
relocation types, triggering warnings for unsupported ones.

```
% llvm-objdump -S a.o
...
0000000000000000 <foo>:
warning: failed to compute relocation: R_RISCV_SUB_ULEB128, Invalid data was encountered while parsing the file
warning: failed to compute relocation: R_RISCV_SET_ULEB128, Invalid data was encountered while parsing the file
...
```

This change fixes llvm#101544 by declaring support for the two ULEB128
relocation types, silencing the spurious warnings.

---

In DWARF v5 builds, DW_LLE_offset_pair/DW_RLE_offset_pair might be
generated in .debug_loclists/.debug_rnglists with ULEB128 relocations.
They are only read by llvm-dwarfdump to dump section content and verbose
DW_AT_location/DW_AT_ranges output for relocatable files.

The DebugInfoDWARF user (e.g. DWARFDebugRnglists.cpp) calls
`Data.getULEB128` without checking the ULEB128 relocations, as the
unrelocated value holds meaning (refer to the assembler
implementation https://reviews.llvm.org/D157657). This differs from
`.quad .Lfoo`, which requires relocation reading (e.g.
https://reviews.llvm.org/D74404).

Pull Request: llvm#101607

Add custom lowering for `BR_JT` DAG nodes to the `brx.idx` PTX
instruction ([PTX ISA 9.7.13.4. Control Flow Instructions: brx.idx]
(https://docs.nvidia.com/cuda/parallel-thread-execution/#control-flow-instructions-brx-idx)).
Depending on the heuristics in DAG selection, `switch` statements may
now be lowered using `brx.idx`.

Note: this fixes the previous issue in llvm#102400 by adding the isBarrier
attribute to BRX_END

…lvm#102496)

Instead of expanding in RISCVExpandPseudoInsts, expand during
MachineInstr to MCInst lowering.

We weren't doing anything in expansion other than copying operands.

This has received no development work in a while and is slowly bit
rotting as new extensions are added.

At the moment, I don't think this is viable without adding a new
invariant that 32 bit values are always in sign extended form like
Mips64 does. We are very dependent on computeKnownBits and
ComputeNumSignBits in SelectionDAG to remove sign extends created for
ABI reasons. If we can't propagate sign bit information through 64-bit
values in SelectionDAG, we can't effectively clean up those extends.

…vm#102416)

We already ended up with -fptrauth-returns, the feature macro, the lang
opt, and the actual backend lowering.

The only part left is threading it all through PointerAuthOptions, to
drive the addition of the "ptrauth-returns" attribute to generated
functions.
While there, do minor cleanup on ptrauth-function-attributes.c.

This also adds ptrauth_key_return_address to ptrauth.h.

Only return nullptr when we don't have an available QualType.

…n. NFC

…age (llvm#102086)"

This reverts commit 2fe61a5.

Follow on to llvm#101232, as suggested in the comments, narrow the scope of
the preserved analyses.

This provides -fptrauth-auth-traps, which at the frontend level only
controls the addition of the "ptrauth-auth-traps" function attribute.

The attribute in turn controls various aspects of backend codegen, by
providing the guarantee that every "auth" operation generated will trap
on failure.

This can either be delegated to the hardware (if AArch64 FPAC is known
to be available), in which case this attribute doesn't change codegen.
Otherwise, if FPAC isn't available, this asks the backend to emit
additional instructions to check and trap on auth failure.

…llvm#102665)

This updates some code to consistently use cpp::numeric_limits,
the src/__support polyfill for std::numeric_limits, rather than
the C <limits.h> macros.  This is in keeping with the general
C++-oriented style in libc code, and also sidesteps issues about
the new C23 *_WIDTH macros that the compiler-provided header does
not define outside C23 mode.

Bug: https://issues.fuchsia.dev/358196552

…102539)

This class is technically not usable in its current state. When you use
it in a simple C++ project, your compiler will complain about an
incomplete definition of SaveCoreOptions. Normally this isn't a problem,
other classes in the SBAPI do this. The difference is that
SBSaveCoreOptions has a default destructor in the header, so the
compiler will attempt to generate the code for the destructor with an
incomplete definition of the impl type.

All methods for every class, including constructors and destructors,
must have a separate implementation not in a header.

Make sure that the usage of `cppType` and `cppClassName` of type and
attribute definitions/constraints is consistent in TableGen.

- `cppClassName`: The C++ class name of the type or attribute.
- `cppType`: The fully qualified C++ class name: C++ namespace and C++
class name.

Basically, we should always use the fully qualified C++ class name for
parameter types, return types or template arguments.

Also some minor cleanups.

Fixes llvm#57279.

\llvm#92331 tried to make `ObjCARCContractPass` by default, but it caused a
regression on O0 builds and was reverted.
This patch trys to bring that back by:

1. reverts the
[revert](llvm@1579e9c).
2. `createObjCARCContractPass` only on optimized builds.

Tests are updated to refelect the changes. Specifically, all `O0` tests
should not include `ObjCARCContractPass`

Signed-off-by: Peter Rong <PeterRong@meta.com>

)

When a type/attribute is defined in TableGen, a type constraint can be
used for parameters, but the type constraint verification was missing.

Example:
```
def TestTypeVerification : Test_Type<"TestTypeVerification"> {
  let parameters = (ins AnyTypeOf<[I16, I32]>:$param);
  // ...
}
```

No verification code was generated to ensure that `$param` is I16 or
I32.

When type constraints a present, a new method will generated for types
and attributes: `verifyInvariantsImpl`. (The naming is similar to op
verifiers.) The user-provided verifier is called `verify` (no change).
There is now a new entry point to type/attribute verification:
`verifyInvariants`. This function calls both `verifyInvariantsImpl` and
`verify`. If neither of those two verifications are present, the
`verifyInvariants` function is not generated.

When a type/attribute is not defined in TableGen, but a verifier is
needed, users can implement the `verifyInvariants` function. (This
function was previously called `verify`.)

Note for LLVM integration: If you have an attribute/type that is not
defined in TableGen (i.e., just C++), you have to rename the
verification function from `verify` to `verifyInvariants`. (Most
attributes/types have no verification, in which case there is nothing to
do.)

Depends on llvm#102657.

The previous change replaced INT_WIDTH with
cpp::numberic_limits<int>::digits, but these don't have the same
value.  While INT_WIDTH == UINT_WIDTH, not so for ::digits, so
use cpp::numberic_limits<unsigned int>::digits et al instead for
the intended effects.

Bug: https://issues.fuchsia.dev/358196552

Heavily based on work by @vporpo.

…xt (llvm#102662)

In device context managed memory is not available so it makes no sense
to allocate the descriptor using it. Fall back to fir.alloca as it is
handled well in device code.
cuf.free is just dropped.

The previous change missed the second spot doing the same thing.

Bug: https://issues.fuchsia.dev/358196552

- Added a default parsing implementation to `PassOptions` to allow
`Option`/`ListOption` to wrap PassOption objects. This is helpful when
creating meta-pipelines (pass pipelines composed of pass pipelines).
- Updated `ListOption` printing to enable round-tripping the output of
`dump-pass-pipeline` back into `mlir-opt` for more complex structures.

Intrinsics are defined with a bfloat type as of commit
250f2bb, not i16 and i32 storage types.
As such declarations are no longer needed once the correct types are
used.

…() (llvm#102406)

This patch introduces Tracker::emplaceIfTracking(), a wrapper of Tracker::track() that will conditionally create the change object if tracking is enabled.
This patch also removes the `Parent` member field of `IRChangeBase`.

…lvm#101765)

ASTContext::getIntWidth returns 1 if isBooleanType(), and falls back on
getTypeSize in the default case, which itself just returns the Width
from getTypeInfo's returned struct, so can be used in all cases here,
not just for _BitInt types.

Certain tests within the compiler-rt subproject encountered "command not
found" errors when using lit's internal shell, particularly when trying
to use the `DIR` environment variable. When checking with the command
`LIT_USE_INTERNAL_SHELL=1 ninja check-compiler-rt`, I encountered the
following error:
```
********************
Testing: 
FAIL: SanitizerCommon-ubsan-i386-Linux :: sanitizer_coverage_trace_pc_guard-init.cpp (146 of 9570)
******************** TEST 'SanitizerCommon-ubsan-i386-Linux :: sanitizer_coverage_trace_pc_guard-init.cpp' FAILED ********************
Exit Code: 127

Command Output (stdout):
--
# RUN: at line 5
DIR=/usr/local/google/home/harinidonthula/llvm-project/build/runtimes/runtimes-bins/compiler-rt/test/sanitizer_common/ubsan-i386-Linux/Output/sanitizer_coverage_trace_pc_guard-init.cpp.tmp_workdir
# executed command: DIR=/usr/local/google/home/harinidonthula/llvm-project/build/runtimes/runtimes-bins/compiler-rt/test/sanitizer_common/ubsan-i386-Linux/Output/sanitizer_coverage_trace_pc_guard-init.cpp.tmp_workdir
# .---command stderr------------
# | 'DIR=/usr/local/google/home/harinidonthula/llvm-project/build/runtimes/runtimes-bins/compiler-rt/test/sanitizer_common/ubsan-i386-Linux/Output/sanitizer_coverage_trace_pc_guard-init.cpp.tmp_workdir': command not found
# `-----------------------------
# error: command failed with exit status: 127
```
In this patch, I resolved these issues by removing the use of the `DIR`
environment variable. Instead, the tests now directly utilize
`%t_workdir` for managing temporary directories. Additionally, I
simplified the tests by embedding the clang command arguments directly
into the test scripts, which avoids complications with environment
variable expansion under lit's internal shell.

This fix ensures that the tests run smoothly with lit's internal shell
and prevents the "command not found" errors, improving the reliability
of the test suite when executed in this environment.

fixes: llvm#102395
[link to
RFC](https://discourse.llvm.org/t/rfc-enabling-the-lit-internal-shell-by-default/80179)

)

In TargetLowering::expandFixedPointMul when expanding fixed point
multiplication, and when using a widened MUL as strategy for the
lowering, there was a bug resulting in assertion failures like this:
   Assertion `VT.isVector() == N1.getValueType().isVector() &&
   "SIGN_EXTEND result type type should be vector iff the operand "
   "type is vector!"' failed.

Problem was that we did not consider that VT could be a vector type
when setting up the WideVT. This patch should fix that bug.

The previous patch removing the fenv requirement for str to float had an
error that got missed due to a lack of tests. This patch fixes the issue
and adds tests, as well as updating the existing tests.

Sin/cos/tan fuzzers were having issues with ONE_TWENTY_EIGHT_OVER_PI, so
the LIBC_TARGET_CPU_HAS_FMA ifdef statement got moved from the
sin/cos/tan .cpp files to the range_reduction_double_common.cpp file.

This patch replaces some of the remaining uses of Tracker::track() to
Tracker::emplaceIfTracking().

While manual compiles can specify full file paths and build automation
tools use full, unique paths in practice, it's not clear whether it's a
general good practice to enforce full paths (fail a build if relative
paths are used).

`NumDefs == 1` condition [1] should hold true for many internal-linkage
vtables as long as full paths are indeed used to salvage the marginal
performance when local-linkage vtables are imported due to indirect
reference.
llvm#100448 (comment)
has more details.

[1]
https://github.com/llvm/llvm-project/pull/100448/files#diff-e7cb370fee46f0f773f2b5429dfab36b75126d3909ae98ee87ff3d0e3f75c6e9R215

This patch introduces the SingleLLVMInstructionImpl class which
implements a couple of functions shared across all Instructions that map
to a single LLVM Instructions. This avoids code replication.

…tributor pass (llvm#101760)

… `AMDGPU.h`

…2653)

Does not yet add it to the pass pipeline. Somehow it causes
2 tests to assert in SelectionDAG, in functions without any
control flow.

…lvm#102654)

… casts

nsan will port msan_allocator.cpp and msan_thread.cpp. Clean up the two
files first.

Without this patch, the constructor arguments come from
SmallVectorImpl, not ArrayRef.  This patch switches them to ArrayRef
so that we can construct SmallVector with a single argument.

Note that LLVM Programmer’s Manual prefers ArrayRef to SmallVectorImpl
for flexibility.

…2713)