* `operator<=>` for `iota_view::iterator` was enabled in 8320017b
    * Removed P2405R0 which was not accepted and seems inactive
      (https://github.com/cplusplus/papers/issues/1075)
    * Added the previously missing `operator==` for `filesystem::space_info`
      to the tracking list.
    * Updated the "Assignee" for `string_view`, `string` as Mark de Wever
      mentioned he is working on them in Discord
    * Updated the status of the items for which I sent review requests
      yesterday.

Reviewed By: #libc, Mordante

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

Fixes code in OrderedChangedData<T>::report which assumes that a string will only appear once in Before/After.

Reviewed By: jamieschmeiser

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

Use opaque pointers and update_test_checks.py

Precommit a test

The LegalizerHelper misses the code to lower G_MUL to a library call,
which this change adds.

Reviewed By: arsenm

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

When using AdditionalArguments in a GICombinerHelper, the generator
does not put a space between the type and the name.

E.g.

let AdditionalArguments = [GICombinerHelperArg<"bool", "IsSomething">];

ends up as

boolIsSomething) const;

in the generated file. This change adds a space between the type and the name.

Reviewed By: aemerson

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

rGcf97e0ec makes $x18 to be treated as callee-saved in functions with
Windows calling convention on non-Windows OSes.

Here we mark $x18 as callee-saved for functions with Windows calling
convention on Darwin, as well as on other non-Windows platforms, in
order to prevent some miscompilations (like miscompilation of
win64cc-darwin-backup-x18.ll).

Since getCalleeSavedRegs doesn't return x18 in list of callee-saved
registers, assignCalleeSavedSpillSlots and determineCalleeSaves
consider different sets of registers as callee-saved. It causes an
error:
```
Assertion failed: ((!HasCalleeSavedStackSize || getCalleeSavedStackSize() == Size) && "Invalid size calculated for callee saves"), function getCalleeSavedStackSize, file
AArch64MachineFunctionInfo.h, line 292.
```

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

We will switch all UndefValue to PoisonValue in follow up patches.

Reviewed By: kito-cheng

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

Instructions.

We will switch all UndefValue to PoisonValue in follow up patches.

Thanks for Kito to help on verification with their interanl testsuite.

Reviewed By: kito-cheng

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

Instructions.

We will switch all UndefValue to PoisonValue in follow up patches.

Reviewed By: kito-cheng

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

vcompress.

We will switch all UndefValue to PoisonValue in follow up patches.

Reviewed By: kito-cheng

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

vwcvtu, vfabs and vfneg.

We will switch all UndefValue to PoisonValue in follow up patches.

Reviewed By: kito-cheng

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

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

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

Remove redundant code that can never execute due to preceeding logic checks in the code.

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

The ZERO register should be exposed as a constant physical register through the interface TargetRegisterInfo::isConstantPhysReg.

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

This improves the formatting of the generated files. That allows it to
remove the clang-format step in D129668.

Reviewed By: ldionne, #libc

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

The macro is only enabled when the Clang is used with
-fexperimental-library.

Reviewed By: ldionne, #libc

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

I think these pseudos will exist when the post-RA scheduler runs
so they should have sched classes.

Reviewed By: monkchiang

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

Reviewed By: monkchiang

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

In the 2e29b013 we introduce a specific solving algorithm
that analyzes the VGPR to SGPR copies use chains and either lowers
the copy to v_readfirstlane_b32 or converts the whole chain to VALU forms.
Same time we still have the code that blindly converts to VALU REG_SEQUENCE and PHIs
in case they produce SGPR but have VGPRs input operands. In case the REG_SEQUENCE and PHIs
are in the VGPR to SGPR copy use chain, and this chain was considered long enough to convert
copy to v_readfistlane_b32, further lowering them to VALU leads to several kinds of issues.
At first, we have v_readfistlane_b32 which is completely useless because most parts of its use chain
were moved to VALU forms. Second, we may encounter subtle bugs related to the EXEC-dependent CF
because of the weird mixing of SALU and VALU instructions.
This change removes the code that moves REG_SEQUENCE and PHIs to VALU. Instead, we use the fact
that both REG_SEQUENCE and PHIs have copy semantics. That is, if they define SGPR but have VGPR inputs,
we insert VGPR to SGPR copies to make them pure SGPR. Then, the new copies are processed by the common
VGPR to SGPR lowering algorithm.
This is Part 2 in the series of commits aiming at the massive refactoring of the SIFixSGPRCopies pass.

Reviewed By: rampitec

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

This pass seems to have very little effect because all it does is hoist
some instructions, but it is followed later in the codegen pipeline by
the IR CodeSinking pass which does the opposite.

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

llvm-reduce: reorder passes to run the ones first that delete function bodies; this makes reductions go faster

This improves a corner case where v_fmac can be converted to v_fma on
GFX10+ even if it has a literal operand.

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

The Clang compiler generates internal functions for OpenMP. Current
patch marks these functions as artificial.

Reviewed By: aprantl

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

This extends the handling of uniform memory operations to handle the case where a store is storing a loop invariant value. Unlike the general case of a store to an invariant address where we must use the last active lane, in this case we can use any lane since all lanes must produce the same result.

For context, the basic structure of the existing code and how the change fits in:
* First, we select a widening strategy. (The result is irrelevant for this patch.)
* Then we determine if a computation is uniform within all lanes of VF. (Note this is the uniform-per-part definition, not LAI's uniform across all unrolled iterations definition.)
* If it is, we overrule the widening strategy, and unconditionally scalarize.
* VPReplicationRecipe - which is what actually does the scalarization - knows how to handle unform-per-part values including for scalable vectors. However, we do need to know that the expression is safe to execute without predication - e.g. the uniform mem op was unconditional in the original loop. (This part was split off and already landed.)

An obvious question is why not simply implement the generic case? The answer is that I'm going to, but doing so without a canonicalization towards uniform causes regressions due to bad interaction with scalarization/uniformity of values feeding the uniform mem-op. This patch is needed to avoid those regressions.

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

This supports checks in C1801-C1805 for derived type with BIND attribute.
The other compilers such as 'gfortran' and 'ifort' do not report error
for C1802 and C1805, so emit warnings for them.

Reviewed By: klausler

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

The semantic checks and runtime have been supported. This supports the
lowering of intrinsic ABORT.

`gfortran` prints a backtrace before abort, unless `-fno-backtrace` is
given. This is good to use. The intrinsic BACKTRACE is not supported
yet, so add TODO in the runtime.

This extention is needed in SPEC2017 521.wrf_r in
https://github.com/llvm/llvm-project/issues/55955.

Reviewed By: klausler

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

As Fortran 2018 18.2.3.6, the intrinsic `c_loc(x)` gets the C address
of argument `x`. It returns the scalar of type C_PTR. As defined in
iso_c_binding in `flang/module/__fortran_builtins.f90`, C_PTR is the
derived type with only one component of integer 64.

This supports the lowering of intrinsic module procedure `c_loc` by
converting the address of argument into integer 64, where the argument
is lowered as Box and the address is generated using fir.box_addr.

The lowering of intrinsic `c_funloc` has the similar characteristic and
will be supported later.

The execution tests for various data types are in issue
https://github.com/llvm/llvm-project/issues/56552.

Reviewed By: Jean Perier

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

The problem Alexander reported on D127982 was caused by an optimization
for AVX512-FP16 instruction. We must limit it to the feature enabled only.

During the investigation, I found we didn't expand for fp_round/fp_extend
without F16C. This may result runtime crash, so change them too.

Reviewed By: RKSimon

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

s/true/ArchSpec::ExactMatch
s/false/ArchSpec::CompatibleMatch

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

I went over the output of the following mess of a command:

`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

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

This reverts commit 0cc3c184.

The changes did not account for templated code where one instantiation
may trigger the diagnostic but other instantiations will not, as in:
```
template <int I, class T>
void foo(int x) {
    bool b1 = (x & sizeof(T)) == 8;
    bool b2 = (x & I) == 8;
    bool b3 = (x & 4) == 8;
}

void run(int x) {
    foo<4, int>(8);
}
```

If you're having trouble getting a yaml2obj macro expansion to do what
you want, it's useful to be able to print the output of the
preprocessing to see what your macros expanded to //before// going
into the YAML processing phase.

yaml2obj has its own preprocessing system which isn't the same as any
other well-known thing like cpp. So there's no way to do this macro
expansion via another tool: yaml2obj will have to do it itself.

In this commit I add an `-E` flag to yaml2obj to do that.

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

Add a new IRBuilderBase::CreateIntrinsic which takes the return type and
argument values for the intrinsic call but does not take an explicit
list of types to mangle. Instead the builder works this out from the
intrinsic declaration and the types of the supplied arguments.

This means that the mangling is hidden from the client, which in turn
means that intrinsic definitions can change which arguments are mangled
without requiring any changes to the client code.

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

This folds a v4i32 Mul(And(Srl(X, 15), 0x10001), 0xffff) into a v8i16
CMLTz instruction. The Srl and And extract the top bit (whether the
input is negative) and the Mul sets all values in the i16 half to all
1/0 depending on if that top bit was set. This is equivalent to a v8i16
CMLTz instruction. The same applies to other sizes with equivalent
constants.

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

TestInlineStepping.py is flaky while TestUseSourceCache.py fails on
Windows 11 only. Marked them skipped to make buildbot happy.

This patch adds constant folder for TanhOp which only supports single and double precision floating-point.

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

Multiple top-level MLIR documents did not have a table of contents tag,
making them harder to nagivate.