Fix UBSan error detected in TestDataFormatterObjCCF.py and
TestDataFormatterObjCNSDate.py:

Scalar.cpp:698:27: runtime error: -4.96303e+08 is outside the range of
representable values of type 'unsigned long long'.

In most cases, this doesn't have much impact: the destructors just call
the base class destructor anyway.  A few subclasses of ConstantExpr
actually store non-trivial data, though. Make sure we clean up
appropriately.

This is sort of ugly, but I don't see a good alternative given the
constraints.

Issue found by asan buildbots running the testcase for D80330.

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

D79164/2596da31 changed getCFInstrCost to return 1 per default.
AArch64 did not have its own implementation, hence the throughput cost
of CFI instructions is overestimated. On most cores, most branches should
be predicated and essentially free throughput wise.

This restores a 9% performance regression on a SPEC2006 benchmark on
AArch64 with -O3 LTO & PGO.

This patch effectively restores pre 2596da31 behavior for AArch64
and undoes the AArch64 test changes of the patch.

Reviewers: samparker, dmgreen, anemet

Reviewed By: samparker

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

Fix a typo in the documentation and simplify the condition to drop
braces. Addresses post-commit review of https://reviews.llvm.org/D82647.

This replaces the switch statement implementation in the clang's
X86.cpp with a lookup table in X86TargetParser.cpp.

I've used constexpr and copy of the FeatureBitset from
SubtargetFeature.h to store the features in a lookup table.
After the lookup the bitset is translated into strings for use
by the rest of the frontend code.

I had to modify the implementation of the FeatureBitset to avoid
bugs in gcc 5.5 constexpr handling. It seems to not like the
same array entry to be used on the left side and right hand side
of an assignment or &= or |=. I've also used uint32_t instead of
uint64_t and sized based on the X86::CPU_FEATURE_MAX.

I've initialized the features for different CPUs outside of the
table so that we can express inheritance in an adhoc way. This
was one of the big limitations of the switch and we had resorted
to labels and gotos.

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

These features exist in earlier CPUs, but were deprecated on
znver1/znver2. While working on D82731 I accidentally copied
them from the earlier CPU. And nothing caught my mistake. Having
these additional checks would have helped.

If the addend of the fma is zero, common sense would suggest that we can
convert fma x, y, 0.0 to fmul x, y. This comes up with some user code
that was expecting the first fma in an unrolled loop to simplify to a
fmul.

Floating point often does not follow naive common sense though. Alive
suggests that this should be guarded by nsz (as fadd -0.0, 0.0 = 0.0).
fma x, y, -0.0 is always valid.

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

Summary:
Follow up to D81736. Move getOpenMPDirectiveKind, getOpenMPClauseKind, getOpenMPDirectiveName and
getOpenMPClauseName to the new tablegen code generation. The code is generated in a new file named OMP.cpp.inc

Reviewers: jdoerfert, jdenny, thakis

Reviewed By: jdoerfert, jdenny

Subscribers: mgorny, yaxunl, hiraditya, guansong, sstefan1, llvm-commits, thakis

Tags: #llvm

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

Summary:
This changes the casing of MLIRGPUtoGPURuntimeTransforms to be consistent
with other transform libraries.

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

This change lets LLVM use the LC_BUILD_VERSION command when building for macOS 10.14, iOS 12, tvOS 12, and watchOS 5.
Additionally, this change ensures that new platforms like Apple Silicon macOS / Mac Catalyst,
and simulators running on Apple Silicon alway use LC_BUILD_VERSION with the OS version set to the
minimum supported OS version if the deployment target version is older.

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

Summary:
This changes the casing of MLIRGPUtoNVVMTransforms to be consistent
with other transform libraries.

Reviewers: stephenneuendorffer, herhut

Reviewed By: herhut

Subscribers: jholewinski, mgorny, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, grosul1, Kayjukh, jurahul, msifontes

Tags: #mlir

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

Summary:
This changes the casing of MLIRGPUtoROCDLTransforms to be consistent
with other transform libraries.

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

Added a 'RefactorConditionVariables' option to control how the check handles condition variables

Reviewed By: aaron.ballman

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

Summary:
The following feature macros have been added:

__ARM_FEATURE_SVE_BF16

__ARM_FEATURE_SVE_MATMUL_INT8

__ARM_FEATURE_SVE_MATMUL_FP32

__ARM_FEATURE_SVE_MATMUL_FP64

The driver has been updated to enable them accordingly to the value of
the target feature passed at command line.

The SVE ACLE tests using the macros have been modified to work with
the target feature instead of passing the macro at command line.

Reviewers: sdesmalen, efriedma, c-rhodes, kmclaughlin, SjoerdMeijer, rengolin

Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits

Tags: #clang

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

Implement `-change` option for install-name-tool. The behavior exactly
matches that of cctools. Depends on D82410.

Reviewed By: jhenderson, smeenai

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

Implement `-id` option for install-name-tool. Differences from cctool's
behavior:
 - Does **NOT** throw an error if multiple -id options are specified.
    Instead, picks the last one.
 - Throws an error in case empty id is specified.

Reviewed By: jhenderson, smeenai

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

This reduces peak memory on my test case from 1960.14MB to 1700.63MB
(-260MB, -13.2%) with no measurable impact on CPU time. I'm currently
working with a publics stream that is about 277MB. Before this change,
we would allocate 277MB of heap memory, serialize publics into them,
hold onto that heap memory, open the PDB, and commit into it.  After
this change, we defer the serialization until commit time.

In the last change I made to public writing, I re-sorted the list of
publics multiple times in place to avoid allocating new temporary data
structures. Deferring serialization until later requires that we don't
reorder the publics. Instead of sorting the publics, I partially
construct the hash table data structures, store a publics index in them,
and then sort the hash table data structures. Later, I replace the index
with the symbol record offset.

This change also addresses a FIXME and moves the list of global and
public records from GSIHashStreamBuilder to GSIStreamBuilder. Now that
publics aren't being serialized, it makes even less sense to store them
as a list of CVSymbol records. The hash table used to deduplicate
globals is moved as well, since that is specific to globals, and not
publics.

Reviewed By: aganea, hans

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

See D82735 / rG1a6cebb4

debugserver and lldb

This patch improves the heuristics for correctly identifying simulator binaries on Darwin and adds support for simulators running on Apple Silicon.

rdar://problem/64046344

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

Reviewers: efriedma, paquette, david-arm, kmclaughlin

Reviewed By: david-arm

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, danielkiss, llvm-commits

Tags: #llvm

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

Reviewers: efriedma, lhames, sdesmalen, fpetrogalli

Reviewed By: lhames, sdesmalen

Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

Patch by Nathan Froyd!

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

That makes it easier to exclude from the build if one wants to build libc++
without support for the deprecated std::random_shuffle.

Disable some of the warnings from clang-tidy, in particular,
`readability-identifier-naming`. They add clutter to reviews.

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

In RISC-V vector extension, users could group multiple vector registers
as one pseudo register. In mixed width operations, users could use
partial vector registers to reduce the register pressure. The parameter
to control register grouping and partial use is called LMUL. LMUL is a
part of the type. So, we have a bunch of vector types. In order to
support all these types, we need new MVT types in LLVM. In this patch, I
added several MVT types that are used in RISC-V vector implementation.
This is a standalone patch for MVT types without RISC-V related implementation.

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

Rename `future*` encoding test files to include ISA3.1 in the file name
and combine with exisitng ISA3.1 instruction encoding tests that were
added into `p10*` test files.

Keeping the `p10*` files for now to ensure we don't add more to it.
Will remove once all ISA3.1 instruction are implemented.

If -Wl,object_path_lto,<lto-filename>.o is not passed at link time
when compiling and linking in separate steps with -flto and -g, the
temporary file used for Link Time Optimization is deleted by the linker,
so the executable is missing debug symbols and can't be easily debugged,
and dsymutil can't be run.

Document this behaviour.

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

This patch stops the fabs intrinsic from blocking tail predication.

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

Noticed by clang-tidy performance-unnecessary-value-param warning.

This patch stops the usub_sat and ssub_sat intrinsics from blocking tail predication.

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

I ran into an error while trying to build libc++abi for a platform that
doesn't have <sys/types.h>. I couldn't find what <sys/types.h> was used
for in the header, so I think it's fine to remove it.

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