Changes

TableGen/GlobalISel: Allow inst matcher to check multiple opcodes

This is to initially handleg immAllOnesV, which should match
G_BUILD_VECTOR or G_BUILD_VECTOR_TRUNC. In the future, it could be
used for other patterns cases that map to multiple G_* instructions,
such as G_ADD and G_PTR_ADD.

[lldb] type category name common completion

1. Added a new common completion TypeCategoryNames to provide a list of category names for completion;
2. Applied the completion to these commands: type category delete/enable/disable/list/define;
3. Added a related test case;
4. Bound the completion to the arguments of the type 'eArgTypeName'.

Reviewed By: teemperor, JDevlieghere

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

[flang][openacc] Fix reduction operator parsing/unparsing

Update the way reduction operator are defined for the OpenACC parser.

Reviewed By: klausler

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

[AMDGPU, docs] Fix typos

Reviewed By: t-tye, Flakebi

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

[TSan][Darwin] Handle NULL argument in interceptor

Handle NULL address argument in the `mach_vm_[de]allocate()`
interceptors and fix test: `Assignment 2` is not valid if we weren't
able to re-allocate memory.

rdar://67680613

AMDGPU: Add flag to disable promotion of uniform i16 ops

This interferes with GlobalISel's much better handling of the
situation.

This should really be disable for GlobalISel. However, the fallback
only re-runs the selection passes, and doesn't go back and rerun any
codegen IR passes. I haven't come up with a good solution to this
problem.

Revert D85812 "[coroutine] should disable inline before calling coro split"

This reverts commit 2e43acfed89b1903de473f682c65878bdebc395a.

LLVMCoroutines (the library which contains Coroutines.h) depends on LLVMipo (the
library which contains SampleProfile.cpp). It is inappropriate for
SampleProfile.cpp to depent on Coroutines.h (circular dependency).

The test inverted dependencies as well:
llvm/test/Transforms/Coroutines/coro-inline.ll uses -sample-profile.

Add hashing of the .text section to ProcessMinidump.

Breakpad will always have a UUID for binaries when it creates minidump files. If an ELF files has a GNU build ID, it will use that. If it doesn't, it will create one by hashing up to the first 4096 bytes of the .text section. LLDB was not able to load these binaries even when we had the right binary because the UUID didn't match. LLDB will use the GNU build ID first as the main UUID for a binary and fallback onto a 8 byte CRC if a binary doesn't have one. With this fix, we will check for the Breakpad hash or the Facebook hash (a modified version of the breakpad hash that collides a bit less) and accept binaries when these hashes match.

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

[mlir] Add Index Type, Floating Point Type and None Type subclasses to python bindings.

Based on the PyType and PyConcreteType classes, this patch implements the bindings of Index Type, Floating Point Type and None Type subclasses.
These three subclasses share the same binding strategy:
- The function pointer `isaFunction` points to `mlirTypeIsA***`.
- The `mlir***TypeGet` C API is bound with the `***Type` constructor in the python side.

Reviewed By: stellaraccident

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

[PowerPC] Extend custom lower of vector truncate to handle wider input

Current custom lowering of truncate vector handles a source of up to 128 bits, but that only uses one of the two shuffle vector operands. Extend it to use both operands to handle 256 bit sources.

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

[NFC][InstCombine] Adjust naming for some methods to match coding standards

Requested as preparatory cleanup in https://reviews.llvm.org/D86306#inline-799065

[NFC][InstCombine] Multi-level aggregate test for phi-of-insertvalue pattern

See https://reviews.llvm.org/D86306

[flang] Fix bug accessing implicit variable in specification expression

A specification expression can reference an implicitly declared variable
in the host procedure. Because we have to process specification parts
before execution parts, this may be the first time we encounter the
variable. We were assuming the variable was implicitly declared in the
scope where it was encountered, leading to an error because local
variables may not be referenced in specification expressions.

The fix is to tentatively create the implicit variable in the host
procedure because that is the only way the specification expression can
be valid. We mark it with the flag `ImplicitOrError` to indicate that
either it must be implicitly defined in the host (by being mentioned in
the execution part) or else its use turned out to be an error.
We need to apply the implicit type rules of the host, which requires
some changes to implicit typing.

Variables in common blocks are allowed to appear in specification expressions
(because they are not locals) but the common block definition may not appear
until after their use. To handle this we create common block symbols and object
entities for each common block object during the `PreSpecificationConstruct`
pass. This allows us to remove the corresponding code in the main visitor and
`commonBlockInfo_.curr`. The change in order of processing causes some
different error messages to be emitted.

Some cleanup is included with this change:
- In `ExpressionAnalyzer`, if an unresolved name is encountered but
  no error has been reported, emit an internal error.
- Change `ImplicitRulesVisitor` to hide the `ImplicitRules` object
  that implements it. Change the interface to pass in names rather
  than having to get the first character of the name.
- Change `DeclareObjectEntity` to have the `attrs` argument default
  to an empty set; that is the typical case.
- In `Pre(parser::SpecificationPart)` use "structured bindings" to
  give names to the pieces that make up a specification-part.
- Enhance `parser::Unwrap` to unwrap `Statement` and `UnlabeledStatement`
  and make use of that in PreSpecificationConstruct.

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

[Scalarizer] Avoid updating the name of globals

The "takeName" logic at the end of ScalarizerVisitor::finish
could end up renaming global variables when having simplified
and extractelement instruction to simply pick a single vector
element. If the input vector to the extractelement instruction
held pointers to global variables we ended up renaming the global
variable.
The patch make sure we only take the name of the replaced Op when
we have added new instructions that might need a useful name.

Reviewed By: lebedev.ri

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

Move special va_list handling to kmp_os.h

Instead of copying and pasting the same `#ifdef` expressions in multiple
places, define a type and a pair of macros in `kmp_os.h`, to handle
whether `va_list` is pointer-like or not:

* `kmp_va_list` is the type to use for `__kmp_fork_call()`
* `kmp_va_deref()` dereferences a `va_list`, if necessary
* `kmp_va_addr_of()` takes the address of a `va_list`, if necessary

Also add FreeBSD to the list of OSes that has a non pointer-like
va_list. This can now be easily extended to other OSes too.

Reviewed By: AndreyChurbanov

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

Add <stdarg.h> include to kmp_os.h, to get the va_list type, required
after cde8f4c164a2. Sort system includes, while here.

[llvm-libtool-darwin] Add support for -V option

The -V option in cctools' libtool prints out the version number and
performs any specified operation. Add this option to LLVM's version.
cctools is more forgiving of invalid command lines when -V is specified,
but I think it's better to give errors instead of silently producing no
output.

Unfortunately, when -V is present, options that would otherwise be
required aren't anymore, so we need to perform some manual argument
validation.

Reviewed By: alexshap

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

[compiler-rt] Disable ranlib when using libtool

libtool already produces a table of contents, and ranlib just gives
spurious errors because it doesn't understand universal binaries.

Reviewed By: phosek

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

[runtimes] Remove TOOLCHAIN_TOOLS specialization

{builtin,runtime}_register_target passes a TOOLCHAIN_TOOLS list, whereas
{builtin,runtime}_default_target does notl. The explicit TOOLCHAIN_TOOLS
list matches what LLVMExternalProjectUtils would have set anyway,
barring some target-specific adjustments, and those target-specific
adjustments seem valuable, so let's drop the explicit TOOLCHAIN_TOOLS
list and let LLVMExternalProjectUtils take care of it.

Reviewed By: phosek

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

[runtimes] Use llvm-libtool-darwin for runtimes build

It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.

Reviewed By: phosek

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

[InstCombine] add tests for insert+extract demanded elements; NFC

[SLP] avoid 'tmp' names in regression tests; NFC

That can cause problems for update_test_checks.py (it warns when updating this file).

[InstCombine] improve demanded element analysis for vector insert-of-extract

InstCombine currently has odd rules for folding insert-extract chains to shuffles,
so we miss collapsing seemingly simple cases as shown in the tests here.

But poison makes this not quite as easy as we might have guessed. Alive2 tests to
show the subtle difference (similar to the regression tests):
https://alive2.llvm.org/ce/z/hp4hv3 (this is ok)
https://alive2.llvm.org/ce/z/ehEWaN (poison leakage)

SLP tends to create these patterns (as shown in the SLP tests), and this could
help with solving PR16739.

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

[TSan][libdispatch] Add interceptors for dispatch_barrier_async_and_wait()

Add interceptors for the barrier variants of the "async and wait"
dispatch API family.

[libunwind] Remove static_assert / __has_feature macros

The static_assert macro broke on GCC when a scope had two asserts and a
condition that depended on a template parameter. Remove the macro and
rely on the compiler's C++11 static_assert feature.

The __has_feature macro was only used here to determine whether to
define the static_assert macro.

Reviewed By: mstorsjo, #libunwind

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

[PowerPC] Handle SUBFIC in reg+reg -> reg+imm transformation

We initially missed the subtract-immediate in this transformation.
This patch just adds that.

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

[TSan][libdispatch] Add interceptors for dispatch_barrier_async_and_wait(), pt. 2

Also intercept these target functions on Linux.

AMDGPU: Have a few selection failure tests check both paths

SelectionDAG and GlobalISel take different failure paths for these and
end up producing different failure errors. Check both so the test
passes when the default is switched.

[X86] Copy the tuning features and scheduler model from pentium4/x86-64 to generic

This is preparation for making clang default to -mtune=generic when no -march is specified. This will allow the default tuning to be "generic" even though our default march is "pentium4" or "x86-64".

To avoid llc lit test regressions, if no mcpu is specified, I've defaulted tune to use i586 to match the old tuning settings of no CPU. Some tests explicitly used -mcpu=generic which I've removed so they instead get this default of architecture features from generic and tune from i586.

I updated one llvm-mca test to check a different CPU since generic has a scheduler model now

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

[PowerPC] Do not use FISel for calls and TOC-based accesses with PC-Rel

PC-Relative addressing introduces a fair bit of complexity for correctly
eliminating TOC accesses. FastISel does not include any of that handling so we
miscompile code with -mcpu=pwr10 -O0 if it includes an external call that
FastISel does not handle followed by any of the following:

    Floating point constant materialization
    Materialization of a GlobalValue
    Call that FastISel does handle

This patch switches to SDISel for any of the above.

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

AMDGPU/GlobalISel: Handle AGPRs used for SGPR operands.

We would still need to waterfall if the value were somehow an AGPR,
and also need to explicitly copy to a VGPR.

[lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID

When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we also use it to find
kexts. Since these files are already contained in the reproducer,
there's no reason to call out to an external tool. If the tool returns a
different result, e.g. because the dSYM got garbage collected, it will
break reproducer replay. The SymbolFileProvider solves the issue by
mapping UUIDs to module and symbol paths in the reproducer.

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

[x86][AArch64] adjust fast-math-flags in tests; NFC

This goes with the proposal in D86403.

[DAGCombine]: Fold X/Sqrt(X) to Sqrt(X)

With FMF ( "nsz" and " reassoc") fold X/Sqrt(X) to Sqrt(X).

This is done after targets have the chance to produce a
reciprocal sqrt estimate sequence because that expansion
is probably more efficient than an expansion of a
non-reciprocal sqrt. That is also why we deferred doing
this transform in IR (D85709).

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

[LLDB] Fix how ValueObjectVariable handles DW_AT_const_value when the DWARFExpression holds the data that represents a constant value

In some cases when we have a DW_AT_const_value and the data can be found in the
DWARFExpression then ValueObjectVariable does not handle it properly and we end
up with an extracting data from value failed error.

The test is a very stripped down assembly file since reproducing this relies on the results of compiling with -O1 which may not be stable over time.

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

Fix test for D77924.

The trailing 'L' was missing in the expectation.

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

[LLDB] Fix SVE offset calculation in NativeRegisterContextLinux_arm64

There was typo left from changes in CalculateSVEOffset where we moved
FPSR/FPCR offset calculation into WriteRegister and ReadRegister.

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