[lldb] Use Optional::{has_value,value,value_or}

Revert "[PhaseOrdering] add test for issue #50778; NFC"

This reverts commit cdc012fa2696434689c872abc4797a1ee8284ddf.
This accidentally deleted a test file (not sure how that became
part of the commit).

[PhaseOrdering] add test for issue #50778; NFC

Several different passes are involved to get the expected IR,
and we don't want that to break again.

AMDGPU: Use tablegen patterns for buffer global and flat atomic fadd

Remove manual selection for atomic fadd from global-isel.
Stop pre-isel translation to AtomicLoadFAdd/G_ATOMICRMW_FADD
which corresponds to llvm-ir's atomicrmw fadd instruction.

global and flat atomic fadd patterns changes:
Split rtn/no-rtn patterns
Add missing patterns or fix predicates
Remove atomicrmw patterns for v2f16 (atomic rmw doesn't support vectors).
Patterns now check addrspace of pointer, added patterns for flat intrinsic.
with global addrspace pointer that selects into global atomic instruction.

buffer atomic fadd patterns changes:
Rdit patterns to import into global-isel.
Remove gfx6/gfx7 _addr64 and _offset patterns.
Remove patterns that can't be reached (same pattern but different feature).

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

AMDGPU: Improve atomicrmw fadd selection

Use same atomicrmw fadd expansion rules for gfx908, gfx940 and gfx11
as for gfx90a. Add missing globalisel legalizer support for flat
atomicrmw fadd f32 on gfx940 and gfx11.
Isel support for gfx11 will be added in D130579.

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

AMDGPU: Add detailed buffer, global and flat atomic fadd tests

Precommit for D130579 that will remove manual selection and use
patterns from td files. Tests are grouped based on target features.

All patterns have rtn and no-rtn versions.

buffer atomics patterns are selected based on the intrinsic used
(raw or struct) and the offset operand (imm or vgpr):
_offset raw with imm offset
_offen raw with vgpr offset (or large imm offset)
_idxen struct with imm offset
_bothen struct with vgpr offset (or large imm offset)

global and flat atomics are selected via intrinsic or the atomicrmw fadd.
atomicrmw tests have amdgpu-unsafe-fp-atomics=true and non-system scope
since they get expanded otherwise. atomicrmw fadd does not support vector
type, test float and double.

global atomics patterns are selected based on address type via (global or
flat) intrinsic or atomicrmw fadd with global address(addrspace(1)*).
'no suffix' vgpr addrspace(1)* address
_saddr sgpr addrspace(1)* address

flat atomics patterns are selected via (flat)intrinsic or atomicrmw fadd
with flat address (* - address space 0).

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

[AMDGPU] Add FeatureFlatAtomicFaddF32Inst

Feature used by targets that have flat_atomic_add_f32 instruction
(gfx940 and gfx11). Remove isGFX940GFX11Plus.
Add hasFlatAtomicFaddF32Inst Subtarget check for codegen.

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

[SLP] Fix cost model w.r.t. operand properties

We allow the target to report different costs depending on properties of the operands; given this, we have to make sure we pass the right set of operands and account for the fact that different scalar instructions can have operands with different properties.

As a motivating example, consider a set of multiplies which each multiply by a constant (but not all the same constant). Most of the constants are power of two (but not all).

If the target doesn't have support for non-uniform constant immediates, this will likely require constant materialization and a non-uniform multiply. However, depending on the balance of target costs for constant scalar multiplies vs a single vector multiply, this might or might not be a profitable vectorization.

This ends up basically being a rewrite of the existing code. Normally, I'd scope the change more narrowly, but I kept noticing things which seemed highly suspicious, and none of the existing code appears to have any test coverage at all. I think this is a case where simply throwing out the existing code and starting from scratch is reasonable.

This is a follow on to Alexey's D126885, but also handles the arithmetic instruction case since the existing code appears to have the same problem.

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

[Docs] [HLSL] Add IR reference for HLSL

HLSL uses a variety of named IR metadata and attributes to convey
additional information from the frontend to the backend. This document
tries to capture and document the named annotations to provide a
reference for future contributors.

Reviewed By: python3kgae

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

[flang] Prevent a bad folding rewrite

When a subexpression does not have both constant elements and
a constant shape, folding is rewriting it into a vector of its
elements.  This is of course wrong when the shape shows that
the result has rank greater than 1.

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

Allow getting template args for ClassTemplateSpecializations

Modifies clang_Cursor_getNumTemplateArguments() and friends to work on
Struct, Class and ClassTemplatePartialSpecialization decls as well as
functions.

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

[mlir] Add map_nested_foreach_thread_to_gpu_blocks op to transform dialect

This revision adds a new op `map_nested_foreach_thread_to_gpu_blocks` to transform dialect.
If `generate_gpu_launch` argument is given, the op first generates `gpu_launch`. Otherwise, `target` must be `gpu_launch`. The op searches top level `scf.foreach_threads` inside the `gpu_launch` and distributes them with gpu.block_id attribute.
Loop mapping is explicit and given by the map_nested_foreach_thread_to_gpu_blocks op. Mapping is done one-to-one, therefore the loops disappear.
It also adds `gpu dialect` as dependent since the new op can create `gpu::LaunchOp` for given `scf::ForeachThreadOp`.

Reviewed By: nicolasvasilache

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

[LoopDeletion] Invalidate SCEV after moving instruction.

LoopDeletion may hoist instructions out of a loop using
makeLoopInvariant without invalidating the SCEV for the moved
instruction.

Moving the instruction to a different block may change its
cached block disposition, so invalidate the cached info.

Fixes #57837.

[sanitizer_common] Restore sanitizer_procmaps_solaris.cpp compilation on Solaris 11.3

When upstream `compiler-rt` was recently imported into GCC's
`libsanitizer`, Solaris 11.3 bootstrap broke because in 11.3
`<sys/procfs.h>` doesn't mix with largefile compilation.  I'd caused this
in D129837 <https://reviews.llvm.org/D129837> where I forgot that the code
still needs to support Solaris 11.3.

Fixed by restoring the `#undef _FILE_OFFSET_BITS`.

Tested on `sparc-sun-solaris2.11` and `amd64-pc-solaris2.11` (Solaris 11.4)
in LLVM and both Solaris 11.3 and 11.4 in GCC.

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

Fix gcc warning about ambiguous if-else chain

Fixes warnings introduced by D111968

[clang] Make --ld-path= work with -fuse-ld=lld

This allows using --ld-path= to set a custom linker path, while
still informing clang that the binary at that path is an lld built
at the same revision as clang, so that clang can make assumptions
about the flags it supports, its output format, etc.

This currently only has an observable effect on Darwin.

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

[TTI] Add OperandValueProperties::OP_NegatedPowerOf2 enum (PR51436)

The mul by constant costmodels handle power-of-2 constants, but not negated-power-of-2, despite the backends handling both.

This patch adds the OperandValueProperties::OP_NegatedPowerOf2 enum and wires it for use for basic mul cost analysis and SLP handling.

Fixes #50778

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

[FunctionAttrs] Add tests for inaccessiblememonly (NFC)

[LLDB] Fix "memory region --all" when there is no ABI plugin

There are two conditions for the loop exit. Either we hit LLDB_INVALID_ADDRESS
or the ABI tells us we are beyond mappable memory.

I made a mistake in that second part that meant if you had no ABI plugin
--all would stop on the first loop and return nothing.

If there's no ABI plugin we should only check for LLDB_INVALID_ADDRESS.

Depends on D134029

Reviewed By: labath

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

[LLDB] Properly return errors from "memory region --all"

When I wrote the initial version I forgot that a region being
unmapped is not an error. There are real errors that we don't
want to hide, such as the remote not supporting the
qMemoryRegionInfo packet (gdbserver does not).

Reviewed By: labath

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

[NFC]: AArch64-SVE

modify some comments

[FunctionAttrs] Use MemoryLocation::getOrNone() when infering memory attrs

MemoryLocation::getOrNone() already has the necessary logic to
handle different instruction types. Use it, rather than repeating
a subset of the logic. This adds support for previously unhandled
instructions like atomicrmw.

[LoopVersioning] Invalidate SCEV for phi if new values are added.

After 20d798bd47ec5191d, SCEV looks through PHIs with a single incoming
value. This means adding a new incoming value may change the SCEV for a
phi. Add missing invalidation when an existing PHI is reused during
LoopVersioning. New incoming values will be added later from the
versioned loop.

Similar issues have been fixed by also adding missing invalidation.

Fixes #57825.

Note that the test case unfortunately requires running loop-vectorize
followed by loop-load-elimination, which does the actual versioning. I
don't think it is possible to reproduce the failure without that
combination.

[LV] Add test for #57912.

Add test showing miscompilation during epilogue vectorization with SVE.

[lldb][TypeSystemClang] Deduce lldb::eEncodingUint for unsigned enum types

The motivating issue was the following:
```
$ cat main.cpp
enum class EnumVals : uint16_t {
    VAL1 = 0
};

struct Foo {
    EnumVals b1 : 4;
};

int main() {
    // Assign value out-of-range if
    // bit-field were signed
    Foo f{.b1 = (EnumVals)8};

    return 0; // Break here
}

(lldb) script
>>> lldb.frame.FindVariable("f").GetChildMemberWithName("b1").GetValueAsUnsigned()
4294967288
```

In the above example we observe a unsigned integer wrap-around
because we sign-extended the bit-fields underlying Scalar value
before casting it to an unsigned. The sign extension occurs because
we don't mark APSInt::IsUnsigned == true correctly when extracting
the value from memory (in Value::ResolveValue). The reason why sign
extension causes the wraparound is that the value we're assigning
to the bit-field is out-of-range (if it were a signed bit-field),
which causes `Scalar::sext` to left-fill the Scalar with 1s.

This patch corrects GetEncoding to account for unsigned enum types.
With this change the Scalar would be zero-extended instead.

This is mainly a convenience fix which well-formed code wouldn't
encounter.

rdar://99785324

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

[BasicAA] Clean up calculation of FMRB from attributes

The current implementation for call sites is pretty convoluted
when you take the underlying implementation of the used APIs
into account. We will query the call site attributes, and then
fall back to the function attributes while taking into account
operand bundles. However, getModRefBehavior() already has it's
own (more accurate) logic for combining call-site FMRB with
function FMRB.

Clean this up by extracting a function that only fetches FMRB
from attributes, which can be directly used in getModRefBehavior()
for functions, and needs to be combined with an operand-bundle
respecting fallback in the call site case.

One caveat (that makes this non-NFC) is that CallBase function
attribute lookups allow using attributes from functions with
mismatching signature. To ensure we don't regress quality, do
the same for the function FMRB fallback.

Remove an unused var decl, NFC.

[AArch64]Remove svget/svset/svcreate from llvm

This patch removes the aarch64 instrinsic svget/svset/svcreate from llvm.
It also implements the InstCombine for vector.extract that used to be in svget.

Depends on: D131547

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

[flang][NFC] Fix typo

[LV] Convert sve-epilog-vect.ll to use opaque pointers.

[AggressiveInstCombine] Combine consecutive loads which are being merged to form a wider load.

The patch simplifies some of the patterns as below

1. (ZExt(L1) << shift1) | (ZExt(L2) << shift2) -> ZExt(L3) << shift1
2. (ZExt(L1) << shift1) | ZExt(L2) -> ZExt(L3)

The pattern is indicative of the fact that the loads are being merged to a wider load and the only use of this pattern is with a wider load. In this case for a non-atomic/non-volatile loads reduce the pattern to a combined load which would improve the cost of inlining, unrolling, vectorization etc.

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

[Attribute] Clean up test prefixes (NFC)

Now that the legacy PM is no longer tested, the huge matrix of
test prefixes used by attributor tests is no longer needed and very
confusing for the casual reader. Reduce the prefixes down to just
CHECK, TUNIT and CGSCC.

[NFC] update_llc_test_checks llvm/test/CodeGen/ARM/memcpy-inline.ll

[clang] Fix the bogus diagnostic introduced by the newly-added UsingTemplate Kind.

Reviewed By: sammccall

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

[MemorySSA] Convert tests to use opaque pointers (NFC)

[IR] Handle assume intrinsics in hasClobberingOperandBundle()

Operand bundles on assumes do not read or write -- we correctly
modelled the read side of this, but not the write side. In practice
this did not matter because of how the method is used, but this
will become relevant for a future patch.

[Arm][AArch64] Make getArchFeatures to use TargetParser.def

Prefixing the the SubArch with plus sign makes the ArchFeature name.

Reviewed By: DavidSpickett

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

[flang] Add TODOs for some FORALL assignments with Pointers and Allocatables

Add TODO for whole array allocatable assignment inside FORALL
Whole allocatable array assignment inside FORALL are otherwise currently
hitting more cryptic asserts.

Add TODO in FORALL assignment when a designator appear with a part ref
that is an allocatable or pointer component (a(i)%pointer%k). The lowering
code does not handle this case well because of the pointer dereference.

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

[CMake] Add clang-bolt target

This patch adds `CLANG_BOLT_INSTRUMENT` option that applies BOLT instrumentation
to Clang, performs a bootstrap build with the resulting Clang, merges resulting
fdata files into a single profile file, and uses it to perform BOLT optimization
on the original Clang binary.

The projects and targets used for bootstrap/profile collection are configurable via
`CLANG_BOLT_INSTRUMENT_PROJECTS` and `CLANG_BOLT_INSTRUMENT_TARGETS`.
The defaults are "llvm" and "count" respectively, which results in a profile with
~5.3B dynamically executed instructions.

The intended use of the functionality is through BOLT CMake cache file, similar
to PGO 2-stage build:
```
cmake <llvm-project>/llvm -C <llvm-project>/clang/cmake/caches/BOLT.cmake
ninja clang++-bolt # pulls clang-bolt
```

Stats with a recent checkout (clang-16), pre-built BOLT and Clang, 72vCPU/224G
| CMake configure with host Clang + BOLT.cmake | 1m6.592s
| Instrumenting Clang with BOLT | 2m50.508s
| CMake configure `llvm` with instrumented Clang | 5m46.364s (~5x slowdown)
| CMake build `not` with instrumented Clang |0m6.456s
| Merging fdata files | 0m9.439s
| Optimizing Clang with BOLT | 0m39.201s

Building Clang:
```cmake ../llvm-project/llvm -DCMAKE_C_COMPILER=... -DCMAKE_CXX_COMPILER=...
  -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
  -DLLVM_TARGETS_TO_BUILD=Native -GNinja```

| | Release | BOLT-optimized
| cmake | 0m24.016s | 0m22.333s
| ninja clang | 5m55.692s | 4m35.122s

I know it's not rigorous, but shows a ballpark figure.

Reviewed By: phosek

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

[C++] [Modules] Add a test case for mocking implementation for std modules

I found this with the patch: https://reviews.llvm.org/D131858. It breaks
my local implementation but not the in-tree test cases. So I reduce the
failure and submit the test case. The more testing should be always
good.

[llvm-dwarfutil][DWARFv5] fix reading of DW_FORM_addrx attribute.

llvm::dwarfutil::ObjFileAddressMap::relocateIndexedAddr() does not
read address value. The relocateIndexedAddr() should not relocate
the address as the linked binary has already resolved relocations.
But it should read the value. This patch adds the reading value
of the address.

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

[flang] Load allocatable or pointer box of namelist item from common block

If a namelist item is an allocatable or pointer and is also part of a common
block, the box should be loaded from the common block ref.

Reviewed By: PeteSteinfeld

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

Introduce predicate for a atomic operations in GMIR

Reviewed By: arsenm, sameerds

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

[BOLT] Support building bolt when LLVM_LINK_LLVM_DYLIB is ON

This does *not* link with libLLVM, but with static archives instead. Not
super-great, but at least the build works, which is probably better than
failing.

Related to #57551

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

[mlir][memref] fix overflow in realloc

Reviewed By: aartbik

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

[mlir] Add `parseEllipsis`

To `AsmParser` and also to the assembly format

Reviewed By: rriddle

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

[Clang][NFC] Make unused flag `-fopenmp-new-driver` help hidden

Summary:
This flag was deprecated awhile back but still shows up when using
`clang --help`. This patch just gets rid of it but keeps its interface
for backward compatibility.

[bazel] Respect llvm_target_list in llvm-exegesis

- 47afaf2eb02b1424a9aba241ccd02393a0cbc648 changed llvm-exegesis cmake rules
- 5b2f838db42ea190fdda147a33b5f0fcc8145689 ported them to bazel, but did so by adding all the `lib/{target}/*.cpp` sources in exegesis to the build rule
- c7bf9d084d037aa6c8fd479be9ccdf963dc59e10 removed it, because it breaks users who don't build Mips and fail when building `lib/Mips/*.cpp`. But that in turn breaks those who *do* build the Mips target.

This should hopefully fix it for the final time by using selectively build subdirectories of exegesis target libs using llvm_target_exegesis, which is derived from llvm_targets, and is the list that can vary based on the downstream user.

I verified this builds with and without `Mips` in the `DEFAULT_TARGETS` configure list, and also double checked with `bazel query --output=build @llvm-project//llvm:Exegesis` that `lib/Mips/Target.cpp` is being included if and only if `Mips` is in the target list.

Reviewed By: aeubanks

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

[OpenMP][AMDGPU] Enable OpenMP device runtime build for gfx110[0123]

Add OpenMP device runtime build support for the gfx1100, gfx1101,
gfx1102, and gfx1103 targets.

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

[DAG] Move one-use add of splat to base of scatter/gather

This extends the uniform base transform used with scatter/gather to support one-use vector adds-of-splats with a non-zero base. This has the effect of essentially reassociating an add from vector to scalar domain.

The motivation is to improve the lowering of scatter/gather operations fed by complex geps.

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

[OpenMP][IRBuilder] Added if clause to task

This patch adds support for if clause to task construct in OpenMP
IRBuilder.

Reviewed By: raghavendhra

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

[LoongArch] Add codegen support for atomicrmw add/sub/nand/and/or/xor operation

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

[bazel] Remove "nobuildkite" flag for targets depending on libxml2

The buildbots do have libxml2 installed.

[flang][NFC] Document ambiguous case of DATA in BLOCK

Fortran is not clear about the semantics of

```
  subroutine subr
    integer n = 1
    block
      data n/2/
    end block
  end subroutine
```

which could be interpreted as having two variables, each
named 'n', or as having one variable 'n' with invalid double
initialization.  Precedents from existing compilers are also
in disagreement.

The most common interpretation, however, agrees with a subtle
reading of the standard: BLOCK constructs scope names that have
local specifications, and a DATA statement is a declaration
construct, not a specification construct.  So this example is
*not* acceptable.

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

[FPEnv] Remove inaccurate comments regarding signaling NaN for isless

By draft of C23 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf),
the description for isless macro under 7.12.17.3 says,

The isless macro determines whether its first argument is less than its second
argument. The value of isless(x,y) is always equal to (x)< (y); however, unlike
(x) < (y), isless(x,y) does not raise the invalid floating-point exception when
x and y are unordered and neither is a signaling NaN.

isless should trap when encountering signaling NaN.

Reviewed By: jcranmer-intel, efriedma

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

[mlir][sparse] temporarily disable push back for asan

Reviewed By: Peiming

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

[bazel] Remove Mips from Exegesis cc_library definition

Recent update added 'tools/llvm-exegesis/lib/Mips/*.cpp' to srcs for Exegesis cc_library. This was not needed, and in fact breaks things. This CL removes that one change.

Reviewed By: aeubanks

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

[NFC][MLGO] Introduce logRewardIfNeeded method

This patch introduces a logRewardIfNeeded method to reuse regallocscoring.

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

[mlir][sparse] Introducing a new sparse_tensor.foreach operator.

Reviewed By: aartbik

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

[lit] follow-up 2380c1b609631, check stdout and stderr separately

The error output is cached so it could be out of order with stdout in
some bots.

[lit][unit] avoid adding gtest binary more than once

Due to CMake mis-configurations, some gtest binaries may be added to the test
list more than once. This patch makes lit avoid such cases and issues a
warning when it happens.

[RISCV] Precommit test for scalable strided load/store lowering

Add clang flag equivalent to clang-cl /Zl flag

The /Zl flag omits default C runtime library name from obj files.
This patch just adds an equivalent clang driver flag.

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

Revert "[MemProf] Memprof profile matching and annotation"

This reverts commit a212d8da94d08e229aa8d65283e4b116310bba10, and follow
on fixes 0cd6763fa93159b84d70a5bb602c24996acaafaa,
e9ff53d42feac7fc157718523275619a8106f2f3, and
37c6a25e9ab230e5e21fa34e246d9fec55275df0.

After re-reading the documentation for hash_combine, I don't think this
is the appropriate hash function to use for computing the hash to use as
a stack id in the metadata, since it is not guaranteed to produce stable
values across executions. I have not hit this problem, but plan to
switch to using an MD5 hash. I am hitting an issue with one of the bots
(https://lab.llvm.org/buildbot/#/builders/171/builds/20732)
where the values produced are only the lower 32 bits of the expected
hash values, however, which I assume is related to the implementation of
hash_combine and hash_code.

I believe I fixed all of the other bot failures with the follow on fixes,
which I'll merge into the new version before reapplying.

[llvm] Assert two ValIDs are the same kind before comparing

I suspect the reason for why D134234 was failing sometimes is because
"operator<" for a ValID could compare ValIDs of different kinds but have
the same non-active values and return an incorrect result. This is an
issue if I attempt to store ValIDs of different kinds in an std::map but
we compare different "active" values. For example, if I create an
std::map and store some ValIDs of kind t_GlobalName, then I insert a
ValID of kind t_GlobalID, the current "operator<" will see that one of
the operands is a t_GlobalID and compare it against the UIntVal of other
items in the map, but the other items in the map don't set UIntVal
because they're not t_GlobalIDs, so I compare against a
dummy/uninitialized value.

It seems pretty easy to add mixed ValID kinds into an std::map in
LLParser, so this just asserts that when doing the comparison that both
ValIDs are the same kind.

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

[Pipelines] Introduce DAE after ArgumentPromotion

The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.

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

[RISCV] Disallow scale for scatter/gather

RISCV doesn't actually support a scaled form of indexed load and store. We previously handled this by forming the scaled SDNode, and then doing custom legalization during lowering. This patch instead adds a callback via TLI to prevent formation entirely.

This has two effects:
* First, the GEP gets expanded (and used). Instead of the shift being created with an SDLoc of the memory operation, it has the SDLoc of the GEP instruction. This avoids the scheduler perturbing IR order when there's no reason to.
* Second, we fix what appears to be a bug in index calculation with RV32. The rules for GEPs require index calculation be done in particular bitwidth, and it appears the custom legalization code got this wrong for the case where index type exceeds pointer width. (Or at least, I trust the generic GEP lowering to be correct a lot more.)

The DAGCombiner change to handle VPScatter/VPGather is technically separate, but is required to prevent a regression on those intrinsics.

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

[HLSL] clang codeGen for HLSLNumThreadsAttr

Translate HLSLNumThreadsAttr into function attribute with name "dx.numthreads" and value format as "x,y,z".

Reviewed By: beanz

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

[mlir][sparse] Mark sparse_tensor.concatenate as NoSideEffect

Reviewed By: aartbik

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

[mlir][Linalg] Expose the implementation of the tiling to scf.foreach_thread.

This allows downstream uses to use the implementation of the tiling
itself, while performing other transformations that are necessary to
go with it.

Reviewed By: nicolasvasilache

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

[RISCV] Add codegen test coverage for strided load/store intrinsics

[LazyCallGraph] Handle spurious ref edges when deleting a dead function

Spurious ref edges are ref edges that still exist in the call graph even
though the corresponding IR reference no longer exists. This can cause
issues when deleting a dead function which has a spurious ref edge
pointed at it because currently we expect the dead function's RefSCC to
be trivial.

In the case that the dead function's RefSCC is not trivial, remove all
ref edges from other nodes in the RefSCC to it.

Removing a ref edge can result in splitting RefSCCs. There's actually no
reason to revisit those RefSCCs because currently we only run passes on
SCCs, and we've already added all SCCs in the RefSCC to the worklist.
(as opposed to removing the ref edge in
updateCGAndAnalysisManagerForPass() which can modify the call graph of
SCCs we have not visited yet). We also don't expect that RefSCC
refinement will allow us to glean any more information for optimization
use. Also, doing so would drastically increase the complexity of
LazyCallGraph::removeDeadFunction(), requiring us to return a list of
invalidated RefSCCs and new RefSCCs to add to the worklist.

Fixes #56503

Reviewed By: asbirlea

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

[bazel] Port 47afaf2eb02b1424a9aba241ccd02393a0cbc648 to bazel

[OpenMP][NFC] Fix wavesize build warning in OMPGridValues

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

Add auto source map deduce count statistics

This patch adds auto source map deduce count as a target level statistics.
This will help telemetry to track how many debug sessions benefit from this feature.

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

Reland "[mlir][tensor] Support more cases in MergeConsecutiveExtractSlice"

This relands commit 5d4603a02d0c3e0106b10d245322b1d2072c0c3d.
It cludes fixes to GCC test failures and simplification to
the implementation.

Co-authored-by: Mahesh Ravishankar <ravishankarm@google.com>
Co-authored-by: Christopher Bate <cbate@nvidia.com>

[SelectionDAGBuilder] Simplify how VTs is created for constrained intrinsics. NFC

All constrained intrinsics return a single value. We can directly
convert it to an EVT instead of going through ComputeValueTypes.

Add Load merge tests to AggressiveInstCombine

[AMDGPU] Emit module flag for all code object versions

Reviewed by: Changpeng Fang, Matt Arsenault, Brian Sumner

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

[MemProf] Fix buildbot error due to hasValue deprecation warning

Use has_value instead of hasValue to address a deprecation warning from
a212d8da94d08e229aa8d65283e4b116310bba10. E.g.:

https://lab.llvm.org/buildbot/#/builders/57/builds/22166/steps/5/logs/stdio

[MemProf] Fix buildbot error due to unused variable from bad merge

Fix an unused variable warning introduced by a212d8da94d08e229aa8d65283e4b116310bba10
due to a bad merge with a recent change. E.g. in
https://lab.llvm.org/buildbot/#/builders/77/builds/22095

[ELF] --compress-debug-sections=zstd: ignore error if zstd was not built with ZSTD_MULTITHREAD

[NFC] Remove trailing whitespace in CMake file

[MemProf] Fix buildbot errors by requiring zlib

This should fix errors like the following from using the raw
memprof_pgo.profraw profile in a212d8da94d08e229aa8d65283e4b116310bba10:

profile uses zlib compression but the profile reader was built without zlib support

E.g.
https://lab.llvm.org/buildbot/#/builders/196/builds/18536

[RISCV] Remove support for the unratified Zbe, Zbf, and Zbm extensions.

These extensions do not appear to be on their way to ratification.

[NFC] Update test case to be flexible

As we add more DXIL metadata, these numbers will shift. Using regex
matches and variables will ensure the code still works as expected while
making the test less fragile.

[clang][modules][deps] Preserve module map load order

In `ASTWriter`, input files are sorted based on whether they are system or user. The current implementation used single `std::queue` with `push_back` and `push_front`. This resulted in the user files being reversed.

This patch fixes that by keeping the system/user distinction, but otherwise serializing files in the order they were loaded by the `SourceManager`. This is then used in the dependency scanner to report module map dependencies in the correct order.

Depends on D134224.

Reviewed By: Bigcheese

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

[MemProf] Memprof profile matching and annotation

Profile matching and IR annotation for memprof profiles.

See also related RFCs:
RFC: Sanitizer-based Heap Profiler [1]
RFC: A binary serialization format for MemProf [2]
RFC: IR metadata format for MemProf [3]*

* Note that the IR metadata format has changed from the RFC during
implementation, as described in the preceeding patch adding the basic
metadata and verification support.

The matching is performed during the normal PGO annotation phase, to
ensure that the inlines applied in the IR at that point are a subset
of the inlines in the profiled binary and thus reflected in the
profile's call stacks. This is important because the call frames are
associated with functions in the profile based on the inlining in the
symbolized call stacks, and this simplifies locating the subset of
profile data relevant for matching onto each function's IR.

The PGOInstrumentationUse pass is enhanced to perform matching for
whatever combination of memprof and regular PGO profile data exists in
the profile.

Using the utilities introduced in D128854:
The memprof profile data for each context is converted to "cold" or
"notcold" based on parameterized thresholds for size, access count, and
lifetime. The memprof allocation contexts are trimmed to the minimal
amount of context required to uniquely identify whether the context is
cold or not cold. For allocations where all profiled contexts have the
same allocation type, no memprof metadata is attached and instead the
allocation call is directly annotated with an attribute specifying the
alloction type. This is the same attributed that will be applied to
allocation calls once cloned for different contexts, and later used
during LibCall simplification to emit allocation hints [4].

Depends on D128141 and D128854.

[1] https://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html
[2] https://lists.llvm.org/pipermail/llvm-dev/2021-September/153007.html
[3] https://discourse.llvm.org/t/rfc-ir-metadata-format-for-memprof/59165
[4] https://github.com/google/tcmalloc/commit/ab87cf382dc56784f783f3aaa43d6d0465d5f385

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

[CostModel][X86] Tidyup sdiv/srem/udiv/urem by constant cost tables

Preparation for adding cost kinds handling

This is necessary to eventually unblock D111968

[clang][modules][deps] Report modulemaps describing excluded headers

Module map files describing excluded headers do affect compilation. Track them in the compiler, serialize them into the PCM file and report them in the scanner.

Depends on D134222.

Reviewed By: Bigcheese

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

[DAGCombine] Check both forms of a commutative transform

The transform to fold an add into the base of a scatter/gather was only checking to see if the LHS was a splat.  Included test change indicates that splats are not canonicalized to LHS, and that we need to check both sides.

[RISCV] Precommit test showing scatter addressing gap

[clang][dataflow] Add support for nested method calls.

Extend the context-sensitive analysis to handle a call to a method (of the same
class) from within a method. That, is a member-call expression through `this`.

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

[mlir][MemRef] Simplify extract_strided_metadata(expand_shape)

Add a pattern to the pass that simplifies
extract_strided_metadata(other_op(memref)).

The new pattern gets rid of the expand_shape operation while
materializing its effects on the sizes, and the strides of
the base object.

In other words, this simplification replaces:
```
baseBuffer, offset, sizes, strides =
             extract_strided_metadata(expand_shape(memref))
```

With

```
baseBuffer, offset, baseSizes, baseStrides =
    extract_strided_metadata(memref)
sizes#reassIdx =
    baseSizes#reassDim / product(expandShapeSizes#j,
                                 for j in group excluding
                                   reassIdx)
strides#reassIdx =
    baseStrides#reassDim * product(expandShapeSizes#j,
                                   for j in
                                     reassIdx+1..
                                       reassIdx+group.size-1)
```

Where `reassIdx` is a reassociation index for the group at
`reassDim` and `expandShapeSizes#j` is either:
- The constant size at dimension j, derived directly from the
  result type of the expand_shape op, or
- An affine expression: baseSizes#reassDim / product of all
  constant sizes in expandShapeSizes.

Note: baseBuffer and offset are unaffected by the expand_shape
operation.

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

[clang][deps] Report module map describing compiled module

This patch fixes compilation failure with explicit modules caused by scanner not reporting the module map describing the module whose implementation is being compiled.

Below is a breakdown of the attached test case. Note the VFS that makes frameworks "A" and "B" share the same header "shared/H.h".

In non-modular build, Clang skips the last import, since the "shared/H.h" header has already been included.

During scan (or implicit build), the compiler handles "tu.m" as follows:
  * `@import B` imports module "B", as expected,
  * `#import <A/H.h>` is resolved textually (due to `-fmodule-name=A`) to "shared/H.h" (due to the VFS remapping),
  * `#import <B/H.h>` is resolved to import module "A_Private", since the header "shared/H.h" is already known to be part of that module, and the import is skipped.
In the end, the only modular dependency of the TU is "B".

In explicit modular build without `-fmodule-name=A`, TU does depend on module "A_Private" properly, not just textually. Clang therefore builds & loads its PCM, and knows to ignore the last import, since "shared/H.h" is known to be part of "A_Private".

But with current scanner behavior and `-fmodule-name=A` present, the last import fails during explicit build. Clang doesn't know about "A_Private" (it's included textually) and tries to import "B_Private" instead, which it doesn't know about either (the scanner correctly didn't report it as dependency). This is fixed by reporting the module map describing "A" and matching the semantics of implicit build.

Reviewed By: Bigcheese

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

[ELF] Fix std::min error on MacOs

[HLSL] Add resource binding attribute for HLSL.

The resource binding attribute is to set the virtual registers and logical register spaces resources in HLSL are bound to.
Format is ''register(ID,  space)'' like register(t3,  space1).
ID must be start with
t – for shader resource views (SRV),
s – for samplers,
u – for unordered access views (UAV),
b – for constant buffer views (CBV).

Register space is default to space0.

The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl

Reviewed By: aaron.ballman

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

[mlir] Modify LinalgStructuredInterface to allow the computation block to have arguments only for a subset of operands.

Summary:
Currently there is an expectations that there is a corresponsing block argument
for each operand. For some operation, it leads to unused arguments. For example,
in `map`, only input operands are used for the computation.

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

[llvm] Handle dso_local_equivalent in FunctionComparator

This addresses https://github.com/llvm/llvm-project/issues/51066.

Prior to this, dso_local_equivalent would lead to an llvm_unreachable in
a switch in the FunctionComparator. This adds a conservative case in
that switch that just compares the underlying functions.

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

Track .dwo/.dwp loading errors and notify user when viewing variables.

When debugging using Fission (-gsplit-dwarf), we can sometimes have issues loading .dwo files if they are missing or if the path was relative and we were unable to locate the file. We can also skip loading due to DWO ID mismatch or if a .dwp file doesn't contain a matching .dwo file. Also .dwo files could be updated due to a recompile and if the user debugs an executable that was linked against the old .dwo file, it could fail to load the information.

This patch adds a m_dwo_error to DWARFUnit that can be get/set and will cause "frame variable" to show errors when there are .dwo/.dwp issues informing the user about the error.

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