[MLIR] FlatAffineConstraints: Refactored computation of explicit representation for identifiers

This patch refactors the existing implementation of computing an explicit
representation of an identifier as a floordiv in terms of other identifiers and
exposes this computation as a public function.

The computation of this representation is required to support local identifiers
in PresburgerSet subtract, complement and isEqual.

Reviewed By: bondhugula, arjunp

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

[libc] Fix running benchmarks under msan/asan

asan/msan intercepts `aligned_malloc` and misbehave when the requested
alignment is greater than 512.
https://github.com/llvm/llvm-project/blob/b041b613e6fff713fc9ad6dbc73024286fb2fc93/compiler-rt/lib/asan/asan_allocator.cpp#L430-L431

[InstCombine] add test for zext with 'or' op; NFC

[InstCombine] remove unnecessary instructions from test; NFC

[OpenMP] libomp: runtime part of omp_all_memory task dependence implementation.

New omp_all_memory task dependence type is implemented.
Library recognizes the new type via either
(dependence_address == NULL && dependence_flag == 0x80)
or
(dependence_address == SIZE_MAX).
A task with new dependence type depends on each preceding task
with any dependence type (kind of a dependence barrier).

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

[lldb] [Commands] Remove 'append' from 'platform file open' mode

Remove File::eOpenOptionAppend from the mode used by 'platform file
open' command.  According to POSIX, O_APPEND causes all successive
writes to be done at the end of the file.  This effectively makes
the offset argument to 'platform file write' meaningless.

Furthermore, apparently O_APPEND is not implemented reliably everywhere.
The Linux manpage for pwrite(2) suggests that Linux does respect
O_APPEND there while according to POSIX it should not, so the actual
behavior would be dependent on how the vFile:pwrite packet is
implemented on the server.

Ideally, the mode used for opening flags would be provided via options.
However, changing the default mode seems to be a reasonable intermediate
solution.

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

[libc++] Use enable_if_t instead of _EnableIf

I just ran into a compiler error involving __bind_back and some overloads
that were being disabled with _EnableIf. I noticed that the error message
was quite bad and did not mention the reason for the overload being
excluded. Specifically, the error looked like this:

     candidate template ignored: substitution failure [with _Args =
     <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>'

Instead, when using enable_if or enable_if_t, the compiler is clever and
can produce better diagnostics, like so:

     candidate template ignored: requirement 'is_invocable_v<
          std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>,
          std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &,
          ContiguousView>' was not satisfied [with _Args = <ContiguousView>]

Basically, it tries to do a poor man's implementation of concepts, which
is already a lot better than simply complaining about substitution failure.

Hence, this commit uses enable_if_t instead of _EnableIf whenever
possible. That is both more straightforward than using the internal
helper, and also leads to better error messages in those cases.

I understand the motivation for _EnableIf's implementation was to improve
compile-time performance, however I believe striving to improve error
messages is even more important for our QOI, hence this patch. Furthermore,
it is unclear that _EnableIf actually improved compile-time performance
in any noticeable way (see discussion in the review for details).

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

[MLIR] Add loop coalesce utility for affine.for

Add loop coalesce utility for affine.for. This expects loops to have
been normalized a-priori. This works for both constant as well non
constant upper bounds having single/multiple result upper bound affine
map.

With contributions from Arnab Dutta and Uday Bondhugula.

Reviewed By: bondhugula, ayzhuang

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

[MC] Add Subtarget for MAsmParser call to emitCodeAlignment

The call to emitCodeAlignment was missing a STI which is required
after D45962.

emitCodeAlignment has a default parameter of 0 for MaxBytesToEmit.
Explicitly passing 0 here was interpreted as as nullptr for the STI.
This could possibly be avoided by taking STI as a const reference in
emitCodeAlignment.

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

[X86] Add AVX2 test coverage to combine-concatvectors.ll

This will be useful as part of D109348

[FuncSpec] Fix typo in option description. NFC.

[DAG] Fix GT -> GE condition when creating SetCC

79845ed6dfc6511f99 folded some setcc(ashr) conditions to setcc, but got
the condition for NE incorrect, using GT where it should be using GE.

[FuncSpec] Fix test case: only run funcspec and not any other passes. NFC.

[LiveDebugValues] Handle spills of indirect debug values correctly

When handling register spill for indirect debug value LiveDebugValues pass doesn't add
DW_OP_deref operator which may in some cases cause debugger to return value address, instead
of value while machine register holding that address is spilled.

Differential revision: https://reviews.llvm.org/D109142

[clang-offload-bundler] Make Bundle Entry ID backward compatible

Earlier BundleEntryID used to be <OffloadKind>-<Triple>-<GPUArch>.
This used to work because the clang-offload-bundler didn't need
GPUArch explicitly for any bundling/unbundling action. With
unbundleArchive it needs GPUArch to ensure compatibility between
device specific code objects. D93525 enforced triples to have
separators for all 4 components irrespective of number of
components, like "amdgcn-amd-amdhsa--". It was required to
to correctly parse a possible 4th environment component or a GPU.
But, this condition is breaking backward compatibility with
archive libraries compiled with compilers older than D93525.

This patch allows triples to have any number of components with
and without extra separator for empty environment field. Thus,
both the following bundle entry IDs are same:
openmp-amdgcn-amd-amdhsa--gfx906
openmp-amdgcn-amd-amdhsa-gfx906

Reviewed By: yaxunl, grokos

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

[MemCpyOpt] Fix a variety of scalable-type crashes

This patch fixes a variety of crashes resulting from the `MemCpyOptPass`
casting `TypeSize` to a constant integer, whether implicitly or
explicitly.

Since the `MemsetRanges` requires a constant size to work, all but one
of the fixes in this patch simply involve skipping the various
optimizations for scalable types as cleanly as possible.

The optimization of `byval` parameters, however, has been updated to
work on scalable types in theory. In practice, this optimization is only
valid when the length of the `memcpy` is known to be larger than the
scalable type size, which is currently never the case. This could
perhaps be done in the future using the `vscale_range` attribute.

Some implicit casts have been left as they were, under the knowledge
they are only called on aggregate types. These should never be
scalably-sized.

Reviewed By: nikic, tra

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

[AArch64] Regenerate some test checks. NFC

This patch just reruns the update_llc_test_checks script on the AArch64
tests claiming to be updated by the script, cleaning up the output.

[lldb] Support "eflags" register name in generic reg fallback

Enhance the generic register fallback code to support "eflags" register
name in addition to "rflags", as the former is used by gdbserver.  This
permits lldb-server to recognize the generic flags register when
interfacing with gdbserver-style target.xml (i.e. without generic=""
attributes), and therefore aligns ABI plugins' AugmentRegisterInfo()
between lldb-server and gdbserver.

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

[LegalizeTypes][VP] Add promotion support for binary VP ops

This patch extends the preliminary support for vector-predicated (VP)
operation legalization to include promotion of illegal integer vector
types.

Integer promotion of binary VP operations is relatively simple and
piggy-backs on the non-VP logic, but passing the two extra mask and VP
operands through to the promoted operation.

Tests have been added to the RISC-V target to cover the basic scenarios
for integer promotion for both fixed- and scalable-vector types.

Reviewed By: craig.topper

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

[lldb] [gdb-server] Add tests for more vFile packets

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

[lldb] [Commands] Fix reporting errors in 'platform file read/write'

Fix 'platform file read' and 'platform file write' commands to correctly
detect erraneous return and report it as such.  Currently, errors were
implicitly printed as a return value of -1, and the commands were
assumed to be successful.

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

[lldb] [Process/FreeBSD] Support SaveCore() using PT_COREDUMP

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

[AArch64] Regenerate some test checks. NFC

[AArch64][SME] Fix imm bug in mov vector to tile aliases

Also fixes a warning mentioned in D109359.

Reviewed By: sdesmalen

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

[libcxx] [test] Simplify get_temp_file_name() for mingw

Use the same codepaths as for MSVC. Mingw-w64 does have the _mktemp_s
function; on Vista and newer, msvcrt.dll does contain the function,
which ends up called. (Same thing in the UCRT.) In older versions of
msvcrt.dll (older than what libc++ supports), mingw-w64 provides a
fallback implementation.

This effectively reverts 23323e25f896cf44e6d4519ef38f066e45fe408f (and
d07e5c23b40078dcae13f76b091c9e18763ae44a). That commit tried to fix
unspecified MinGW build breakage.

This reduces the risk of temp name collisions between processes (when
running multiple tests in parallel); the path returned by
GetTempFileName can easily collide with other similar paths.
(_mktemp_s on the other hand tries to avoid such clashes by using
the process id as part of the uniqueness seed.)

This avoids stray random failures in fstreams tests in mingw configurations.

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

[WebAssembly][test] Fix lower-em-sjlj-indirect-setjmp.ll after D109375

[AArch64] Implement extract_subvector for predicates.

This patch implements extract_subvector for predicate types when
the input type is more than twice the size of the subvector that
is being extracted.

Reviewed By: CarolineConcatto

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

[ProfileData] Actually fix Clang -Wcovered-switch-default after D109398

The Clang attribute `enum_extensibility(open)` (2017) is too new.
Just use a cast.

[SimplifyCFG] Preserve knowledge about guarding condition by adding assume

This improvement adds "assume" after removal of branch basing on UB in successor block.

Consider the following example:

```
pred:
  x = ...
  cond = x > 10
  br cond, bb, other.succ

bb:
  phi [nullptr, pred], ... // other possible preds
  load(phi) // UB if we came from pred

other.succ:
  // here we know that x <= 10, but this knowledge is lost
  // after the branch is turned to unconditional unless we
  // preserve it with assume.
```

If we remove the branch basing on knowledge about UB in a successor block,
then the fact that x <= 10 is other.succ might be lost if this condition is
not inferrable from any dominating condition. To preserve this knowledge, we
can add assume intrinsic with (possibly inverted) branch condition.

Patch by Dmitry Bakunevich!

Differential Revision: https://reviews.llvm.org/D109054
Reviewed By: lebedev.ri

Revert GCC -Wnon-virtual-dtor workarounds "[SCEV] Fix GCC -Wnon-virtual-dtor" & "[SampleFDO] Fix -Wnon-virtual-dtor"

This reverts commits 4852c770fe8703145dd2a35395985646ce57a454 and 6df09d6ccbc0cb72d3278cafb592e9bc0e6b84a1.

After D109404, -Wnon-virtual-dtor will not be added when the host compiler is GCC.

[CMake] Don't add -Wnon-virtual-dtor if affected by GCC PR102168

See the discussion on
https://reviews.llvm.org/rG4852c770fe8703145dd2a35395985646ce57a454
The GCC behavior (https://gcc.gnu.org/PR102168) seems unhelpful.

Unconditional -Wnon-virtual-dtor led to other unnecessary workarounds like
6df09d6ccbc0cb72d3278cafb592e9bc0e6b84a1

This patches uses a variant of the 4bb5f44c701402462cb93ef00d46d52382f39f11
check to detect GCC PR102168.

Reviewed By: dblaikie

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

[ProfileData] Fix Clang -Wcovered-switch-default after D109398

[ELF] Infer EM_HEXAGON in getBitcodeMachineKind

[SampleFDO] Allow forward compatibility when adding a new section for extbinary
format.

Currently when we add a new section in the profile format and generate a profile
containing the new section, older compiler which reads the new profile will
issue an error. The forward incompatibility can cause unnecessary churn when
extending the profile. This patch removes the incompatibility when adding a new
section for extbinary format.

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

[AVR] Add support for the tinyAVR 0-series and tinyAVR 1-series

Reviewed By: Dylan McKay, Ben Shi

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

[AArch64] Improve target hook function to decide folding (mul (add x, c1), c2)

Prevent the folding if it leads to worse code.

Reviewed By: dmgreen, kda

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

[X86][MS] Fix the aligement mismatch of vector variable arguments on Win32

The alignment of vector variable arguments in callee side is 4, which is
aligned with MSVC. But the caller aligns them to the size of vector
arguments. It results in run fails. This patch fixes this problem by
trimming it to 4 bytes for variable arguments on Win32.

Fixed vector arguments are passed by pointer on Win32. So they don't have
the problem.

I don't find a doc in MSDN for this calling conversion, so I did several
experiments here: https://godbolt.org/z/n1zn1Gx1z

Reviewed By: rnk

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

[clang] fix transformation of template arguments of 'auto' type constraints

See PR48617.

When assigning the new template arguments to the new TypeLoc, we were looping
on the argument count of the original TypeLoc instead of the new one,
which can be different when packs are present.

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

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

[NFC] Recommit "Regenerate SVE ACLE intrinsics tests"" 2nd try

This reverts 61ddc3d3db9b6c6b163774c7ce9f4d611cbd7c80 to reapply
91eda9c30f33da6ec6da70b59a5f5da6c6397039 after fixing the " |& "
causing failures on windows.

Change-Id: Ib646c803b2274f0f24f9a8932de7aa97003529c5

PR45881: Properly use CXXThisOverride for templated lambda

- `this` used in lambda expression parameter declarations needs no capture.
- Set up CXXThisOverride for default template arguments of a lambda.

A similar fix to this is c3d2ebb60f604.

Reviewed By: aaron.ballman

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

[NPM] Make AddDiscriminators pass required

This is to make sure the pass is not skipped at O0 where optnone is
applied to functions by default.

[SCEV] Use no-self-wrap flags infered from exit structure to compute trip count

The basic problem being solved is that we largely give up when encountering a trip count involving an IV which is not an addrec. We will fall back to the brute force constant eval, but that doesn't have the information about the fact that we can't cycle back through the same set of values.

There's a high level design question of whether this is the right place to handle this, and if not, where that place is. The major alternative here would be to return a conservative upper bound, and then rely on two invocations of indvars to add the facts to the narrow IV, and then reconstruct SCEV. (I have not implemented the alternative and am not 100% sure this would work out.) That's arguably more in line with existing code, but I find this substantially easier to reason about.  During review, no one expressed a strong opinion, so we went with this one.

Differential Revision: D108651

[AArch64] Regenerate some test checks. NFC

[WebAssembly] Error out on indirect uses of setjmp

Both Wasm & Emscripten SjLj handling has a restriction that `setjmp`
cannot be called indirectly. I thought we have been erroring out on
indirect uses of `setjmp`, but some recent CL disrupted the logic and
we are not erroring out anymore.

We currently
1. Collect functions that contain `setjmp` calls in `SetjmpUsers`. This
   only counts direct calls:
   https://github.com/llvm/llvm-project/blob/8f77dc459e31aad6daab89a124fa92067916274c/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp#L869-L878
2. Run `runSjLjOnFunction` only on those `SetjmpUsers`. Within
   `runSjLjOnFunction`, if we see an indirect use of `setjmp`, we error
   out:
   https://github.com/llvm/llvm-project/blob/8f77dc459e31aad6daab89a124fa92067916274c/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp#L1218-L1221

So if there are only indirect setjmp calls within the module,
`SetjmpUsers` will be empty, and `runSjLjOnFunction` is not even entered
once. And the indirect `setjmp` call will error out at link time. So in
this CL we check for the indirect uses of `setjmp` upfront before we
enter `runSjLjOnFunction`.

Also this currently errors out on `invoke @setjmp`, which can only occur
when using Wasm EH + Wasm SjLj within a function. We recently added Wasm
SjLj support but we don't support using Wasm EH + Wasm SjLj in the same
function yet. We plan to add this support very soon, so I don't think
it's worth creating another test file just for this. (This is an error
test so it needs its own file)

Reviewed By: dschuff

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

[NFC][C API] Make LLVMSetInstrParamAlignment's index param type LLVMAttributeIndex

It's the same as unsigned, but clearer in intent.

[clang-tidy] bugprone-infinite-loop: Fix false positives with volatile addresses.

Low-level code may occasionally deal with direct access by concrete addresses
such as 0x1234. Values at these addresses act like globals: they can change
at any time. They typically wear volatile qualifiers.

Suppress all warnings on loops with conditions that involve casting anything to
a pointer-to-...-pointer-to-volatile type.

The closely related bugprone-redundant-branch-condition check
doesn't seem to be affected. Add a test just in case.

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

[NFC] Cleanup off by one indexes in CallBase::dataOperandHasImpliedAttr()

Verified that previously nothing was calling dataOperandHasImpliedAttr()
with AttributeList::ReturnIndex even though we had a code path for it.

Reviewed By: rnk

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

[flang] Implement semantic checks for ELEMENTAL subprograms

Adds missing semantic checks for ELEMENTAL functions and subroutines,
their dummy arguments, and their results from F'2018 15.8.1 C15100-15102.

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

[mlir][sparse] fix typos

Perhaps one of these days I will actually learn how to spell opaque....

Reviewed By: bixia

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

[libc][NFC] Add fenv and string headers to x86_64 headers list.

Revert "[gn build] Add a file that should have been in cfe02847496b856aa"

This reverts commit 6be7f5c354557b661494f94be616d2a8c91a6a1d.
We'll need this file eventually, but it in fact shouldn't have been in
cfe02847496b856aa. It's currently unreferenced.

[gn build] Try to fix win build after cfe02847496b856aa

[Support] Implement getMainExecutable on Solaris

Many `flang` tests currently `FAIL` on Solaris because the module files
aren't found.  I could trace this to `sys::fs::getMainExecutable` not being
implemented.

This patch does this and fixes all affected `flang` tests.

Tested on `amd64-pc-solaris2.11`.

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

[SCEV] Further clarify comments regarding UB and zero stride

Follow on to D109029. I realized we had no mention of mustprogrress in the comment (as it prexisted mustprogress in the codebase). In the process of adding it, I tweaked the preconditions into something I think is more clear. Note that mustprogress is checked in the code.

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

Improve error message when creating an op that isn't registered in the context

This prints a more helpful error for folks who aren't intrinsically
familiar with the system.

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

[MLIR][docs] Clarify language in pass restrictions

Right now all but the last bullet are relying on applied "must not" that
isn't there and the last bullet is a "must".

Reviewed By: mehdi_amini

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

[InstCombine] fold icmp equality with 'or' mask ops

This could go either direction since the instruction
count is the same either way, but there are a few
reasons to prefer this:
1. We already do the related transform with 'and'
   (see just above the new code).
2. We try (too hard) to compensate for not having this
   and possibly other folds in transformZExtICmp(),
   and that leads to bugs like https://llvm.org/PR51762 .
3. Codegen looks better across a variety of targets.

https://alive2.llvm.org/ce/z/uEgn4P

[InstCombine] add tests for icmp with 'or' ops; NFC

[X86] Move newly-added tests into the right file

[NFC][X86] Adjust multi-use tests in extract-lowbits.ll

[AArch64][Global ISel] Add sext/zext of vector extract improvements

This patch adds improvements for sext/zext of a vector extract in Global
ISel.

For example, this piece of code:

define i64 @si64(<4 x i32> %0, i32 %1) {
  %3 = extractelement <4 x i32> %0, i64 1
  %s = sext i32 %3 to i64
  ret i64 %s
}

Used to have this lowering:
si64:
  mov s0, v0.s[1]
  fmov w8, s0
  sxtw x0, w8
  ret

Whereas this patch makes it lower to this:
si64:
  smov x0, v0.h[0]
  ret

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

[NFC][X86] Adjust multi-use tests in clear-lowbits.ll, add 'misc' tests

[gn build] Try to fix mac/intel build after cfe02847496b

The public header lldb/include/lldb/Host/XML.h includes libxml/xmlreader.h,
so this must be a public dep.

[gn build] Try to fix mac/arm build after cfe02847496b856aa

[NFC][X86] Adjust multi-use tests in clear-highbits.ll, add pat. d tests

[gn build] Add a file that should have been in cfe02847496b856aa

[gn build] Attempt to fix linux build after cfe02847496b856aa

[libc++][NFC] Add missing synopsis for node handles

This was manually taken from https://llvm.org/D100311.

[gn build] Add build files for LLDB

This is enough to get the lit-based tests to pass on macOS.

Doesn't yet add build targets for:
- Any LLDB unit tests
- swig bindings
- various targets not needed by lit tests

LLDB has many dependency cycles, something GN doesn't allow. For
that reason, I've omitted some dependency edges. Hopefully we can
clean up the cycles one day.

LLDB has a public/private header distinction, but mostly ignores it.
Many libraries include private headers from other modules.

Since LLDB is the first target the LLVM/GN build that uses Objective-C++
code, add some machinery to the toolchain file to handle that.

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

Don't check if the result of hasAttrSomewhere is non-zero in CallBase::getReturnedArgOperand()

Index is 0 when the return value has the returned attribute. But the
return value cannot have the returned attribute, so the check is
pointless.

Reviewed By: rnk

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

[X86] Don't clobber EBX in stackprobes

On X86, the stackprobe emission code chooses the `R11D` register, which
is illegal on i686.  This ends up wrapping around to `EBX`, which does
not get properly callee-saved within the stack probing prologue,
clobbering the register for the callers.

We fix this by explicitly using `EAX` as the stack probe register.

Reviewed By: pengfei

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

[OpenMP][libomptarget][NFC] Change checkDeviceAndCtors return type to bool.

What is exactly needed is only a boolean. Pulling OFFLOAD_SUCCESS/FAIL only adds confusion.

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

[UseListOrder] Fix use list order for function operands

Functions can have a personality function, as well as prefix and
prologue data as additional operands. Unused operands are assigned
a dummy value of i1* null. This patch addresses multiple issues in
use-list order preservation for these:

 * Fix verify-uselistorder to also enumerate the dummy values.
   This means that now use-list order values of these values are
   shuffled even if there is no other mention of i1* null in the
   module. This results in failures of Assembler/call-arg-is-callee.ll,
   Assembler/opaque-ptr.ll and Bitcode/use-list-order2.ll.
 * The use-list order prediction in ValueEnumerator does not take
   into account the fact that a global may use a value more than
   once and leaves uses in the same global effectively unordered.
   We should be comparing the operand number here, as we do for
   the more general case.
 * While we enumerate all operands of a function together (which
   seems sensible to me), the bitcode reader would first resolve
   prefix data for all function, then prologue data for all
   functions, then personality functions for all functions. Change
   this to resolve all operands for a given function together
   instead.

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

Add missing overloads for Function::addRetAttr(s)

[ConstFold] Support opaque pointers in constexpr GEPs

Support opaque pointers in SymbolicallyEvaluateGEP() by using the
value type of a GlobalValue base or falling back to i8 if there
isn't one. We don't unconditionally generate i8 GEPs here because
that would lose inrange attribues, and because some optimizations
on globals currently rely on GEP types (e.g. the globals SROA
mentioned in the comment).

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

Copy Elementtype Attribute to IR at Link step

Copying IR during linking causes a type mismatch due to the field being missing in IRMover/Valuemapper. Adds the full range of typed attributes including elementtype attribute in the copy functions.

Patch by Chenyang Liu

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

[ELF][test] Improve gitBitcodeMachineKind tests

[llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations

Print relocations interleaved with disassembled instructions for
executables with relocatable sections, e.g. those built with "-Wl,-q".

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

[NFC][InstCombine] Make check for sret in a vararg function clearer

We're trying to get the parameter index of sret and see if it's part of
a function's varargs.

Reviewed By: rnk

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

Reland "[InstCombine] Recognize `((x * y) s/ x) !=/== y` as an signed multiplication overflow check (PR48769)"

This reverts commit 91f7a4fff75179e75d38b692715ae69471668b5e,
relanding commit 13ec913bdf500e2354cc55bf29e2f5d99e0c709e.

The original commit was reverted because of (essentially)
https://bugs.llvm.org/show_bug.cgi?id=35922
which has now been addressed by d0eeb64be5848a7832d13db9d69904db281d02e8.

[libc++] Remove a stray `const` on ranges::data and ranges::ssize. NFCI.

These are specced as `inline constexpr auto`; the extra `const`
isn't doing anything except being inconsistent with the other CPOs.
Now all the implemented CPOs can be detected by
    git grep 'inline constexpr auto.*fn' ../libcxx/include/
and I think that's beautiful.

[libc++] Fix std::to_address(array).

There were basically two bugs here:

When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes
a reference to a const array, and then we dispatch to `__to_address<const int(&)[10]>`,
which, oops, gives us a `const int*` result instead of an `int*` result.
Solution: We need to provide the two standard-specified overloads of
`std::to_address` in exactly the same way that we provide two overloads
of `__to_address`.

When `__to_address` is called on a pointer type, `__to_address(const _Ptr&)`
is disabled so we successfully avoid trying to instantiate pointer_traits of
that pointer type. But when it's called on an array type, it's not disabled
for array types, so we go ahead and instantiate pointer_traits<int[10]>,
which goes boom. Solution: We need to disable `__to_address(const _Ptr&)`
for both pointer and array types. Also disable it for function types,
so that they get the nice error message; and put a test on it.

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

[libc++][NFC] Test span is nothrow trivially destructible

Add tests showing `span` is trivially_destructible and nothrow_destructible.
Note that we do not need to explicitly default the destructor in `span`.

Reviewed By: ldionne, Mordante, #libc

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

[X86ISelLowering] avoid emitting libcalls to __mulodi4()

Similar to D108842, D108844, and D108926.

__has_builtin(builtin_mul_overflow) returns true for 32b x86 targets,
but Clang is deferring to compiler RT when encountering long long types.
This breaks ARCH=i386 + CONFIG_BLK_DEV_NBD=y builds of the Linux kernel
that are using builtin_mul_overflow with these types for these targets.

If the semantics of __has_builtin mean "the compiler resolves these,
always" then we shouldn't conditionally emit a libcall.

This will still need to be worked around in the Linux kernel in order to
continue to support these builds of the Linux kernel for this
target with older releases of clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=28629
Link: https://bugs.llvm.org/show_bug.cgi?id=35922
Link: https://github.com/ClangBuiltLinux/linux/issues/1438
Reviewed By: lebedev.ri, RKSimon

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

[flang] evaluate: Fold SQRT, HYPOT, & CABS

Implement IEEE Real::SQRT() operation, then use it to
also implement Real::HYPOT(), which can then be used directly
to implement Complex::ABS().

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

[lldb] Alphabetize some CMake files a bit better

No observable behavior change, but makes the generated Plugins.def a bit easier
to read.

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

[mlir] Fix SplatOp lowering to the LLVM dialect

The lowering has been incorrectly using the operands of the original op instead
of rewritten operands provided to matchAndRewrite call. This may lead to
spurious materializations and generally invalid IR.

Reviewed By: aartbik

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

[Support] Automatically support `hash_value` when `HashBuilder` support is available.

Use the `HBuilder` interface to provide default implementations of `llvm::hash_value`.

Reviewed By: dexonsmith

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

Greedy set cover implementation of `Merger::Merge`

Extend the existing single-pass algorithm for `Merger::Merge` with an algorithm that gives better results. This new implementation can be used with a new **set_cover_merge=1** flag.

This greedy set cover implementation gives a substantially smaller final corpus (40%-80% less testcases) while preserving the same features/coverage. At the same time, the execution time penalty is not that significant (+50% for ~1M corpus files and far less for smaller corpora). These results were obtained by comparing several targets with varying size corpora.

Change `Merger::CrashResistantMergeInternalStep` to collect all features from each file and not just unique ones. This is needed for the set cover algorithm to work correctly. The implementation of the algorithm in `Merger::SetCoverMerge` uses a bitvector to store features that are covered by a file while performing the pass. Collisions while indexing the bitvector are ignored similarly to the fuzzer.

Reviewed By: morehouse

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

[NFC][support] Extract `IsHashableData` out of class

Extract `HashBuilder::IsHashableData` out of class; it does not depend on
template parametres.

Reviewed By: dexonsmith

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

[X86] X86InstrAVX512.td - remove unused template parameters. NFC.

Identified in D109359

[OpenMP] Add interface for 5.1 scope construct

The new interface only marks begin/end of a scope construct for
corresponding OMPT events, and we can use existing interfaces for
reduction operations.

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

[Analysis, Target, Transforms] Construct SmallVector with iterator ranges (NFC)

[RISCV] Fix "set but not used" warnings

[flang] Fix GetHostProcedure() for main program

It only worked for internal procedures of subprograms,
but must also allow for internal procedures of the
main program.  This broke the use of host-associated
implicitly-typed symbols in specification expressions
of internal procedures.

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

[InstCombine] ror/rol(X, RotAmt) == C --> X == rol/ror(C, RotAmt)   (PR51567)

```
----------------------------------------
define i1 @src(i32 %0) {
%1:
  %2 = fshl i32 %0, i32 %0, i32 25
  %3 = icmp eq i32 %2, 5
  ret i1 %3
}
=>
define i1 @tgt(i32 %0) {
%1:
  %2 = icmp eq i32 %0, 640
  ret i1 %2
}
Transformation seems to be correct!
```

https://alive2.llvm.org/ce/z/GdY8Jm

Solves PR51567

Reviewed By: spatel

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

[IROutliner] Adding outlining for single entry/single exit multiblock regions

Using the similarity found from the IRSimilarity Identifier, we take regions with structural similarity, and deduplicate them into a separate function. The Code Extractor is able to provide most of this functionality.

For simplicity, we start by only outlining regions with a single entry and single exit branch, this reduces the complexity in handling phi nodes outside the region, and handling many sets of outputs for each of the different exit blocks.

Reviewer: paquette

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

[PowerPC] Fixed the crash due to early if conversion with fixed CR fields

This patch adds a fix to do early if conversion to select when
conditional branch not using physical register to prevent the crash when
expanding ISEL instruction.

Reviewed By: lei, kamaub, PowerPC

Differential revision: https://reviews.llvm.org/D108302

[libc++] Provide 'buildhost=<platform> feature for the tests.

The target platform could differ from the host platform for the cross
platform builds. Some tests are depended on the build host features and
they need to determine a proper platform environment.

This commit adds a build host platform name feature for the libc++ tests
in format `buildhost=<platform>`, such as `buildhost=linux`, `buildhost=darwin`,
`buildhost=windows`, etc.

The Windows host gets two features: one `buildhost=windows` and another based
on Windows "sub-system", such as `buildhost=win32`, `buildhost=cygwin`, etc.

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

[lldb] Add missing newline to stderr output on failed attach